3 ms·

Since you asked: Most Chrome and Firefox releases (in my experience) have been relatively minor, and focused on security and bugs. Lets take a look at the last

Since you asked: Most Chrome and Firefox releases (in my experience) have been relatively minor, and focused on security and bugs. Lets take a look at the last 4 releases of Chrome: http://googlechromereleases.blogspot.com/2014/11/stable-channel-update_18.html http://googlechromereleases.blogspot.com/2014/11/stable-chan... http://googlechromereleases.blogspot.com/2014/10/stable-channel-update.html http://googlechromereleases.blogspot.com/2014/10/stable-chan... http://googlechromereleases.blogspot.com/2014/09/stable-channel-update-for-chrome-os.html http://googlechromereleases.blogspot.com/2014/09/stable-chan... http://googlechromereleases.blogspot.com/2014/08/stable-channel-update_26.html http://googlechromereleases.blogspot.com/2014/08/stable-chan... What argument could be made that longer release cycles would mean less bugs? Is there going to be better QA? More stringent testing? Why would shorter release cycles mean less testing? No, longer release cycles would mean similar number of bugs, and security holes would just sit out there longer. Chrome and Firefox is an example of doing it right.

Silhouette 12y ago
Most Chrome and Firefox releases (in my experience) have been relatively minor, and focused on security and bugs. Serious security issues should be fixed as soon as possible anyway. This has absolutely nothing to do with a regular schedule for planned releases, and all of the major browser developers will already issue an immediate out-of-band update for a sufficiently dangerous vulnerability. What argument could be made that longer release cycles would mean less bugs? Well, for one thing, you can't regress something if you don't change it. Both Firefox and Chrome typically introduce a bunch of breaking changes every update. Sometimes these are unintentional bugs. Sometimes they are deliberate policy decisions, and in this case newer features are at far greater risk of backward-incompatible changes, as with the CSS syntax and multimedia controls examples I mentioned in another post to this thread. The thing is, if your site/app used to work and it doesn't work any more after your customer updated their browser, and now you're getting paged in the early hours to be second/third tier support, it is highly unlikely that you care about niceties like whether the browser developers consider the change to be desirable. So if nothing else, every time every browser pushes out a major update, a lot of people building sites or apps need to be testing that their own projects still work, which is clearly a much greater overhead if you do it eight or nine times per browser per year than if you only have to do it once or twice.
- Flimm 12y ago
  Is it not possible to run beta versions of these browsers to catch issues early?
  - Silhouette 12y ago
    You can, but you still have to test against N different versions per year instead of 1, which is still an N-fold increase in testing overhead compared to annual releases. You can automate some aspects of that testing to reduce the burden. However, in the nature of web sites, some things will always need manual examination. No unit test is going to tell you that Chrome has a layout bug where your element that is styled to have a 100px width is being calculated at width 50px anyway and your entire home page doesn't render properly as a result, nor that resizing a responsive page in Firefox so it satisfies different media queries and then changing it back to the original size might result in a different layout (both real examples I've personally seen in recent months, BTW).

Silhouette 12y ago

Most Chrome and Firefox releases (in my experience) have been relatively minor, and focused on security and bugs. Serious security issues should be fixed as soon as possible anyway. This has absolutely nothing to do with a regular schedule for planned releases, and all of the major browser developers will already issue an immediate out-of-band update for a sufficiently dangerous vulnerability. What argument could be made that longer release cycles would mean less bugs? Well, for one thing, you can't regress something if you don't change it. Both Firefox and Chrome typically introduce a bunch of breaking changes every update. Sometimes these are unintentional bugs. Sometimes they are deliberate policy decisions, and in this case newer features are at far greater risk of backward-incompatible changes, as with the CSS syntax and multimedia controls examples I mentioned in another post to this thread. The thing is, if your site/app used to work and it doesn't work any more after your customer updated their browser, and now you're getting paged in the early hours to be second/third tier support, it is highly unlikely that you care about niceties like whether the browser developers consider the change to be desirable. So if nothing else, every time every browser pushes out a major update, a lot of people building sites or apps need to be testing that their own projects still work, which is clearly a much greater overhead if you do it eight or nine times per browser per year than if you only have to do it once or twice.

Flimm 12y ago
Is it not possible to run beta versions of these browsers to catch issues early?
- Silhouette 12y ago
  You can, but you still have to test against N different versions per year instead of 1, which is still an N-fold increase in testing overhead compared to annual releases. You can automate some aspects of that testing to reduce the burden. However, in the nature of web sites, some things will always need manual examination. No unit test is going to tell you that Chrome has a layout bug where your element that is styled to have a 100px width is being calculated at width 50px anyway and your entire home page doesn't render properly as a result, nor that resizing a responsive page in Firefox so it satisfies different media queries and then changing it back to the original size might result in a different layout (both real examples I've personally seen in recent months, BTW).