7 ms·

Sounds like the main story is that they're redefining what a major version number means a la Chrome. Chrome's numbers are not in the same scale as FF and IE to

Sounds like the main story is that they're redefining what a major version number means a la Chrome. Chrome's numbers are not in the same scale as FF and IE too, of course. Users can't tell the difference between Chrome 6 and 7 like one can distinguish FF 2 and 3, or IE 6 and 7. I wonder, though, if Google was just trying to catch IE in version number with Chrome and once it's at 10, they'll stop increasing it so rapidly.

eli 16y ago
Chrome auto-updates and generally always looks the same. I can't imagine why anyone -- users or developers -- would care what version number it's up to.
- IgorPartola 16y ago
  Exactly. In the ideal world, I would simply create a web app, and it would run on all browsers. No more keeping 3 VMs just to do some browser testing. Alas, until there is a high enough price for not following the standard to the letter, we won't see this happen.
- code_duck 16y ago
  My theory is that they wanted to avoid PHB types saying 'Internet Explorer is at version 9 - this new Google browser, only version 3? Is it ready for the enterprise?'.
  - barredo 16y ago
    That's why Microsoft called the new Xbox "Xbox360" instead of Xbox2, because it will _seem_ a less powerful machine in front of a PlayStation3
  - philjr 16y ago
    There's that, but it probably fits better into their development model. If they're continually adding features and not breaking backwards compatibility on a "fixed" timeline, then the major version jumps that Firefox, IE do etc. seem more pointless than anything. If I've got this application that we're continually developing on and we're using a 2 month lifecycle for development ... at what point does it make sense to jump a major version? Never? What's the point of it then? It's the fact that we've become accustomed to major versions representing periods of time. Version numbers should be representative. If it was the case that they used the minor number to represent their two month cycles, then they'd be at 1.11. What's the point of the 1 in that scenario? It's redundant. The major version increments fit in better with their development lifecycle, so why not use it?
    - didroe 16y ago
      I personally find larger version numbers a bit odd. Generally people tend to work better with smaller numbers. I think the Ubuntu system is pretty good, use the major version for the year and have the month as the minor version. The Chrome 2 month releases could go 1.1, 1.3, 1.5, etc. That way they wouldn't chew through so many numbers. Ultimately I guess projects must go through a reset of their versions before they get to really ridiculous numbers.
  - eli 16y ago
    I guess, but I don't even know what version number of Chrome I'm currently running, and I like to think I'm more tech savvy than the average PHB.
  - JonnieCache 16y ago
    This is also part of why MS were obsessed with using calendar years for version numbers, windows 95 and so on. It makes things seem obsolete automatically with the passage of time.
  - mbrubeck 16y ago
    Chrome's 6-week release cycle (with no support or security updates for old versions) is probably a much harder sell to enterprise IT departments than a low version number would be.
- deleted 16y ago
  [deleted]
- Silhouette 16y ago
  > I can't imagine why anyone -- users or developers -- would care what version number it's up to. One reason is that while Chrome's UI may look much the same, its behaviour often changes significantly, and not always for the better. They broke CSS3 rounded corners just as web designers were starting to use them instead of graphics. They made a political decision to remove H.264 support just as the HTML5 video tag was starting to gain traction. There is a reason technical communities develop standards. Unfortunately, the web development community has completely lost the plot in recent years. The W3C have become so slow and politicised that they have become irrelevant. The browser vendors are moving so fast that no-one can keep up. No-one can actually use all of these state-of-the-art features in serious projects anyway, because they don't work in most browsers. As keen as web developers are for long-standing pain points to get fixed and to play with new toys, to get the job done you still have to use the old tried-and-tested techniques anyway as a fall-back for all the browsers that don't support the latest cool stuff. If you have to do that anyway, there isn't much point to using most of that cool stuff in the first place.
  - alanh 16y ago
    Can you elaborate on broken rounded corners? They seem to work just fine for me, always have.
    - Silhouette 16y ago
      If you search the Chromium bug database under "rounded corners", you'll find various issues related to poor antialiasing or worse, with screenshots attached. Basically, rounded corners weren't rendering smoothly, and if there was a border applied then you could even get the wrong colours showing, which looked awful.
mrseb 16y ago
Yeah, this is what I wrote about last week. Until now, every version of Firefox had significant changes -- visual changes, changes to the way you interact with the browser. It now sounds like Firefox will follow Chrome. It will keep the same UI, and simply add new features. Which is fair enough, I guess, if the browser is to become the next platform (for Web apps). It's time for the browser to 'fade' into the background, to give Web apps focus; to empower the apps, rather than interfere with their operation -- much like any other OS!
thisisblurry 16y ago
I doubt that the Chromium authors are concerned about trying to catch IE by having a larger version number. Their development calendar (https://sites.google.com/a/chromium.org/dev/developers/calendar https://sites.google.com/a/chromium.org/dev/developers/calen...) looks as though they have a rigid two-month schedule per version number. I myself am already running version 11 (screenshot: http://jhn.me/4RYO http://jhn.me/4RYO) via their nightly builds.
- code_duck 16y ago
  But why have they chosen to version their software like this, in contrast to every other browser? They could have gone with even numbered point releases.
  - thisisblurry 16y ago
    As per the last paragraph of this post: http://blog.chromium.org/2010/07/release-early-release-often.html http://blog.chromium.org/2010/07/release-early-release-often... "Please don’t read too much into the pace of version number changes - they just mean we are moving through release cycles and we are geared up to get fresher releases into your hands!"
    - code_duck 16y ago
      Thanks, but that actually addresses how they will be moving the whole version numbers up even faster than before, not how they've chosen to use whole version numbers to represent fairly minor milestones, in contrast to established practices.
      - wmf 16y ago
        Would you prefer Linux/SunOS-like version numbers where the major version never increments? When you do a release every 6-8 weeks, they're all going to be minor.
- trezor 16y ago
  I guess at this point version 9 looks OK. You have MSIE 9, Opera 10 etc and we've grown accustomed to those. It's up there at the same level and not particularly out of place. Now look back: the public stable release of Chrome 1 was on 11 December 2008. That's roughly 5 up per year. In another year it will be 15 and then 20. After a while it will start looking silly (like it did with MS Office) and I don't think the question is if they will stop with this aggressive version-numbering, but when. They now have beaten IE to the release of version 9, they will beat Opera for version 11. I'm guessing once they have beaten all the other browsers they will stop and get back to point-releases like everyone else. But not until they are ahead of the curve and say "Your browser only goes to 9 or 10? My browser goes to version 11!". In lack of better words: Pointless or not, I'm guessing they want their browser to be the one which goes to 11, Spinaltap style. The number is all a mind-trick and you have to be a fool not to see the game being played here.
j2d2j2d2 16y ago
I agree. It suggests that version numbers are essentially meaningless when the consumer of the versioned item is only concerned with what is supported. It almost seems reasonable to think any browser level 7 should have full HTML5 compatibility. Level 8 should have IndexDB as the built-in database. I haven't spent a lot of time considering this idea, but I'm attracted to the stability that could be gained from having versions somewhat mapped to implementation standards.
zephjc 16y ago
Chrome is a pretty spankin' good browser, but it's version number system has bugged me, like theyre only doing it to seem like they make advances quicker than other browser vendors.
- bengoodger 16y ago
  Not true. The core elements of the number are major and minor. Major represents a new stable release from the trunk. Minor is a subsequent release from that branch. We almost never do minor. The notable exception was 4.1, which came off the 4.0 branch. We don't emphasize version numbers in our marketing because consumers are almost never aware of what version of the browser they're running other than "latest". Do you know what version of GMail you're using? Neither do I. With this in mind we chose a predictable versioning scheme even if it's somewhat unconventional in the world of desktop software.
Perceval 16y ago
I think Mozilla is also aware of the problematic perception that this particular release generated among onlookers. They've already spun 10 betas and are going to make at least two more betas before the release candidates. It seems like the Firefox 4 project simply got out of control, there was no clear cut-off, features were added willy-nilly throughout the beta process, and the browser (for a while) seemed stuck in perpetual development. It doesn't look good, and doesn't make Mozilla look like they can ship without the temptation to add more or tweak more. Fx1.5 and 2 both had two beta releases. Fx3, 3.5, and 3.6 had five beta releases each. Fx4 is scheduled for at least twelve betas. They need a significant change in their project management, and setting a fast-paced roadmap is probably an aspirational way to force themselves to ship.
- ams6110 16y ago
  It seems like the Firefox 4 project simply got out of control, there was no clear cut-off, features were added willy-nilly throughout the beta process, and the browser (for a while) seemed stuck in perpetual development. It doesn't look good, and doesn't make Mozilla look like they can ship without the temptation to add more or tweak more. Netscape all over again?
- cpeterso 16y ago
  Firefox 4 = Netscape 4? :)
schintan 16y ago
I dont think 95% of users care/know what version their chrome is..especially considering that it updates automatically.
mbrubeck 16y ago
(Disclosure: I work for Mozilla.) Anthony Laforge, the Google program manager in charge of Chrome releases, was kind enough to give a talk at Mozilla's all-hands meeting in December. He gave a version of this presentation: http://techcrunch.com/2011/01/11/google-chrome-release-cycle-slideshow/ http://techcrunch.com/2011/01/11/google-chrome-release-cycle... Each Chrome release is in development for 12 weeks. There are always two 12-week cycles in progress at once, staggered by 6 weeks. So users on the stable channel see a new version every 6 weeks. This has benefits much more profound than just a large number before the dot. For example, developers working on new features actually feel less schedule pressure. If a feature misses the deadline for version N, the team knows they'll have another chance just six weeks later for version N+1. And for users, the browser becomes more like a web app. Do you know what version of GMail you use? Do you notice every time they add fix bugs or improve performance on Google Maps? No - every time you open the app, you simply have the latest version. Laforge mentioned some things about Chrome development that make this work: - Silent background updates. When an update is available on your channel, Chrome downloads it in the background and installs it. The next time you launch the browser, it is running the new version and deletes the old one. Because of this, the majority of Chrome users are up-to-date within days of each release. - Feature switches. Development is done on trunk, but each work-in-progress feature can be disabled with a switch (either a preference, a build option, or a command-line flag). This lets developers work for several cycles before turning a feature on for the stable channel. It also lets product management disable a new feature if bugs are found during beta, without changing any code. Web startup folks might recognize this as the "always ship trunk" pattern used by sites like Flickr: http://news.ycombinator.com/item?id=1463751 http://news.ycombinator.com/item?id=1463751 - No support for old versions. Instead of deciding which "version" to install, Chrome users decide which "channel" to follow. If you are a developer and want to test upcoming changes, use the canary or dev channels. If you want a more tested browser, use the beta or stable channels. New features roll out to each channel in turn. If you are on one of these four channels, you get updates. If you are not, then you don't. (Just like you can't choose to run an old version of GMail or Google Reader.) Mozilla is just starting to talk about the new roadmap and how to achieve it. Chrome's experience is useful, and it was really helpful of Laforge to share it with us. But we're different both technically and organizationally from Chrome, so just blindly copying what they do would not be a good idea. The wiki shows a plan for releases every 3 months (not every 1.5 months like Chrome). We use Mercurial with long-lived project branches (unlike Chrome which uses Subversion and does all development on trunk). And our product differs in some important ways, like the ABI for binary extensions. (Even non-binary Firefox extensions may reach deeper into the browser internals than Chrome extensions.) But we do think that the benefits for users (more frequent improvements to the browser) and developers (more predictable schedule, fewer release delays) are worth pursuing. There are benefits for web developers too, since it reduces the time from when we start implementing new web-facing features (like IndexedDB, or CSS3 transitions) to when you can deploy them to more of your users.

eli 16y ago

Chrome auto-updates and generally always looks the same. I can't imagine why anyone -- users or developers -- would care what version number it's up to.

IgorPartola 16y ago
Exactly. In the ideal world, I would simply create a web app, and it would run on all browsers. No more keeping 3 VMs just to do some browser testing. Alas, until there is a high enough price for not following the standard to the letter, we won't see this happen.
code_duck 16y ago
My theory is that they wanted to avoid PHB types saying 'Internet Explorer is at version 9 - this new Google browser, only version 3? Is it ready for the enterprise?'.
- barredo 16y ago
  That's why Microsoft called the new Xbox "Xbox360" instead of Xbox2, because it will _seem_ a less powerful machine in front of a PlayStation3
- philjr 16y ago
  There's that, but it probably fits better into their development model. If they're continually adding features and not breaking backwards compatibility on a "fixed" timeline, then the major version jumps that Firefox, IE do etc. seem more pointless than anything. If I've got this application that we're continually developing on and we're using a 2 month lifecycle for development ... at what point does it make sense to jump a major version? Never? What's the point of it then? It's the fact that we've become accustomed to major versions representing periods of time. Version numbers should be representative. If it was the case that they used the minor number to represent their two month cycles, then they'd be at 1.11. What's the point of the 1 in that scenario? It's redundant. The major version increments fit in better with their development lifecycle, so why not use it?
  - didroe 16y ago
    I personally find larger version numbers a bit odd. Generally people tend to work better with smaller numbers. I think the Ubuntu system is pretty good, use the major version for the year and have the month as the minor version. The Chrome 2 month releases could go 1.1, 1.3, 1.5, etc. That way they wouldn't chew through so many numbers. Ultimately I guess projects must go through a reset of their versions before they get to really ridiculous numbers.
- eli 16y ago
  I guess, but I don't even know what version number of Chrome I'm currently running, and I like to think I'm more tech savvy than the average PHB.
- JonnieCache 16y ago
  This is also part of why MS were obsessed with using calendar years for version numbers, windows 95 and so on. It makes things seem obsolete automatically with the passage of time.
- mbrubeck 16y ago
  Chrome's 6-week release cycle (with no support or security updates for old versions) is probably a much harder sell to enterprise IT departments than a low version number would be.
deleted 16y ago
[deleted]
Silhouette 16y ago
> I can't imagine why anyone -- users or developers -- would care what version number it's up to. One reason is that while Chrome's UI may look much the same, its behaviour often changes significantly, and not always for the better. They broke CSS3 rounded corners just as web designers were starting to use them instead of graphics. They made a political decision to remove H.264 support just as the HTML5 video tag was starting to gain traction. There is a reason technical communities develop standards. Unfortunately, the web development community has completely lost the plot in recent years. The W3C have become so slow and politicised that they have become irrelevant. The browser vendors are moving so fast that no-one can keep up. No-one can actually use all of these state-of-the-art features in serious projects anyway, because they don't work in most browsers. As keen as web developers are for long-standing pain points to get fixed and to play with new toys, to get the job done you still have to use the old tried-and-tested techniques anyway as a fall-back for all the browsers that don't support the latest cool stuff. If you have to do that anyway, there isn't much point to using most of that cool stuff in the first place.
- alanh 16y ago
  Can you elaborate on broken rounded corners? They seem to work just fine for me, always have.
  - Silhouette 16y ago
    If you search the Chromium bug database under "rounded corners", you'll find various issues related to poor antialiasing or worse, with screenshots attached. Basically, rounded corners weren't rendering smoothly, and if there was a border applied then you could even get the wrong colours showing, which looked awful.

mrseb 16y ago

Yeah, this is what I wrote about last week. Until now, every version of Firefox had significant changes -- visual changes, changes to the way you interact with the browser. It now sounds like Firefox will follow Chrome. It will keep the same UI, and simply add new features. Which is fair enough, I guess, if the browser is to become the next platform (for Web apps). It's time for the browser to 'fade' into the background, to give Web apps focus; to empower the apps, rather than interfere with their operation -- much like any other OS!

thisisblurry 16y ago

I doubt that the Chromium authors are concerned about trying to catch IE by having a larger version number. Their development calendar (https://sites.google.com/a/chromium.org/dev/developers/calendar https://sites.google.com/a/chromium.org/dev/developers/calen...) looks as though they have a rigid two-month schedule per version number. I myself am already running version 11 (screenshot: http://jhn.me/4RYO http://jhn.me/4RYO) via their nightly builds.

code_duck 16y ago
But why have they chosen to version their software like this, in contrast to every other browser? They could have gone with even numbered point releases.
- thisisblurry 16y ago
  As per the last paragraph of this post: http://blog.chromium.org/2010/07/release-early-release-often.html http://blog.chromium.org/2010/07/release-early-release-often... "Please don’t read too much into the pace of version number changes - they just mean we are moving through release cycles and we are geared up to get fresher releases into your hands!"
  - code_duck 16y ago
    Thanks, but that actually addresses how they will be moving the whole version numbers up even faster than before, not how they've chosen to use whole version numbers to represent fairly minor milestones, in contrast to established practices.
    - wmf 16y ago
      Would you prefer Linux/SunOS-like version numbers where the major version never increments? When you do a release every 6-8 weeks, they're all going to be minor.
trezor 16y ago
I guess at this point version 9 looks OK. You have MSIE 9, Opera 10 etc and we've grown accustomed to those. It's up there at the same level and not particularly out of place. Now look back: the public stable release of Chrome 1 was on 11 December 2008. That's roughly 5 up per year. In another year it will be 15 and then 20. After a while it will start looking silly (like it did with MS Office) and I don't think the question is if they will stop with this aggressive version-numbering, but when. They now have beaten IE to the release of version 9, they will beat Opera for version 11. I'm guessing once they have beaten all the other browsers they will stop and get back to point-releases like everyone else. But not until they are ahead of the curve and say "Your browser only goes to 9 or 10? My browser goes to version 11!". In lack of better words: Pointless or not, I'm guessing they want their browser to be the one which goes to 11, Spinaltap style. The number is all a mind-trick and you have to be a fool not to see the game being played here.

j2d2j2d2 16y ago

I agree. It suggests that version numbers are essentially meaningless when the consumer of the versioned item is only concerned with what is supported. It almost seems reasonable to think any browser level 7 should have full HTML5 compatibility. Level 8 should have IndexDB as the built-in database. I haven't spent a lot of time considering this idea, but I'm attracted to the stability that could be gained from having versions somewhat mapped to implementation standards.

zephjc 16y ago

Chrome is a pretty spankin' good browser, but it's version number system has bugged me, like theyre only doing it to seem like they make advances quicker than other browser vendors.

bengoodger 16y ago
Not true. The core elements of the number are major and minor. Major represents a new stable release from the trunk. Minor is a subsequent release from that branch. We almost never do minor. The notable exception was 4.1, which came off the 4.0 branch. We don't emphasize version numbers in our marketing because consumers are almost never aware of what version of the browser they're running other than "latest". Do you know what version of GMail you're using? Neither do I. With this in mind we chose a predictable versioning scheme even if it's somewhat unconventional in the world of desktop software.

Perceval 16y ago

I think Mozilla is also aware of the problematic perception that this particular release generated among onlookers. They've already spun 10 betas and are going to make at least two more betas before the release candidates. It seems like the Firefox 4 project simply got out of control, there was no clear cut-off, features were added willy-nilly throughout the beta process, and the browser (for a while) seemed stuck in perpetual development. It doesn't look good, and doesn't make Mozilla look like they can ship without the temptation to add more or tweak more. Fx1.5 and 2 both had two beta releases. Fx3, 3.5, and 3.6 had five beta releases each. Fx4 is scheduled for at least twelve betas. They need a significant change in their project management, and setting a fast-paced roadmap is probably an aspirational way to force themselves to ship.

ams6110 16y ago
It seems like the Firefox 4 project simply got out of control, there was no clear cut-off, features were added willy-nilly throughout the beta process, and the browser (for a while) seemed stuck in perpetual development. It doesn't look good, and doesn't make Mozilla look like they can ship without the temptation to add more or tweak more. Netscape all over again?
cpeterso 16y ago
Firefox 4 = Netscape 4? :)

schintan 16y ago

I dont think 95% of users care/know what version their chrome is..especially considering that it updates automatically.

mbrubeck 16y ago

(Disclosure: I work for Mozilla.) Anthony Laforge, the Google program manager in charge of Chrome releases, was kind enough to give a talk at Mozilla's all-hands meeting in December. He gave a version of this presentation: http://techcrunch.com/2011/01/11/google-chrome-release-cycle-slideshow/ http://techcrunch.com/2011/01/11/google-chrome-release-cycle... Each Chrome release is in development for 12 weeks. There are always two 12-week cycles in progress at once, staggered by 6 weeks. So users on the stable channel see a new version every 6 weeks. This has benefits much more profound than just a large number before the dot. For example, developers working on new features actually feel less schedule pressure. If a feature misses the deadline for version N, the team knows they'll have another chance just six weeks later for version N+1. And for users, the browser becomes more like a web app. Do you know what version of GMail you use? Do you notice every time they add fix bugs or improve performance on Google Maps? No - every time you open the app, you simply have the latest version. Laforge mentioned some things about Chrome development that make this work: - Silent background updates. When an update is available on your channel, Chrome downloads it in the background and installs it. The next time you launch the browser, it is running the new version and deletes the old one. Because of this, the majority of Chrome users are up-to-date within days of each release. - Feature switches. Development is done on trunk, but each work-in-progress feature can be disabled with a switch (either a preference, a build option, or a command-line flag). This lets developers work for several cycles before turning a feature on for the stable channel. It also lets product management disable a new feature if bugs are found during beta, without changing any code. Web startup folks might recognize this as the "always ship trunk" pattern used by sites like Flickr: http://news.ycombinator.com/item?id=1463751 http://news.ycombinator.com/item?id=1463751 - No support for old versions. Instead of deciding which "version" to install, Chrome users decide which "channel" to follow. If you are a developer and want to test upcoming changes, use the canary or dev channels. If you want a more tested browser, use the beta or stable channels. New features roll out to each channel in turn. If you are on one of these four channels, you get updates. If you are not, then you don't. (Just like you can't choose to run an old version of GMail or Google Reader.) Mozilla is just starting to talk about the new roadmap and how to achieve it. Chrome's experience is useful, and it was really helpful of Laforge to share it with us. But we're different both technically and organizationally from Chrome, so just blindly copying what they do would not be a good idea. The wiki shows a plan for releases every 3 months (not every 1.5 months like Chrome). We use Mercurial with long-lived project branches (unlike Chrome which uses Subversion and does all development on trunk). And our product differs in some important ways, like the ABI for binary extensions. (Even non-binary Firefox extensions may reach deeper into the browser internals than Chrome extensions.) But we do think that the benefits for users (more frequent improvements to the browser) and developers (more predictable schedule, fewer release delays) are worth pursuing. There are benefits for web developers too, since it reduces the time from when we start implementing new web-facing features (like IndexedDB, or CSS3 transitions) to when you can deploy them to more of your users.