“Google is celebrating Chrome’s second birthday by releasing a new stable version of its rapidly evolving browser, offering a slightly simpler user interface, an automatic form filler, and the ability to synchronize extensions and form data across machines.”
It seems like a lot of people criticize Chrome’s versioning system. They think it’s crazy for a two year old project to be at version six.
I think that’s fine. To me, the only purpose of the version number is to signify that one release came before another. There doesn’t have to be major or minor number. Udev, for example, is at version 161. They just increment the number with each release. Systemd is at version 8.
The only reason that release numbers tend to go slowly in most projects is convention. But they are just meaningless numbers, and no system is really “better”, unless it somehow makes managing releases easier (e.g it might make sense for a bug fix update to be 6.1 rather than 7). If a release is not ready for a certain use, it should be labeled with words, not numbers. “5.0 Beta 2” is much better than “4.99.2”.
I should note that my favorite numbering system is by time. 2007.8 tells me exactly how old the software is. Version 6.4.2 tells me nothing if I am not familiar with the history of the project.
With it’s autoupdate and now 6 week release cycle it shouldn’t be hard to see that Google wants Chrome to be like their web apps.
Quick, what version is Google Maps at?
Hi
Versioning, it projects which offer an API is the way you dont like, because its the API version.
for example, KDE has a new release every month and the version number is in x.y.z form (like 4.5.1). 4, is the api version’s number. kdelibs’s api will not change on whole 4 series lifecycle.
in the x.y.z form, y means new feature release. So when moving from 4.4.z to 4.5.z, you know that there will be new features.
and z, means bugfixes. when you update your kde from 4.5.0 to 4.5.1, you know that there will e bugfixes (and translation updates)
Hope it helps you understand why many releases of differrent projects are named like that.
I think the sanest versioning (and the one I use) is the following:
x.y.d.t
x = major release version (this should only be incremented when there is a major change to the software)
y = minor release version (eg major bug fixes, additional features added. Stuff that improves the overall experience without significantly changing the application)
d = compile day / date (like you described yourself, it gives people who don’t know the version history an idea of the age of the app)
t = compile time (this is for developers when building, debugging and packaging so that they 100% know they have the latest builds)
The last two should be automatically populated but the former to should be user incremented.
but as you said, it doesn’t really make a whole lot of difference what people use as it’s just arbitrary numbers.
Skipping past the others philosophy of well-versioned projects, which I thought was interesting.
Those projects being exempt, I think it’s more about the image of saying “see, we’re all grown up now”. On the converse, some projects will continue to profess a “it’s not 1.0 yet so you cannot criticize yet” by using 0.9, 0.9.9/0.99.
I think there are jokes and comics out there from the 90’s, centered around Windows version numbers (1, 2, 3, 3.1, 3.11) and what they mean.
Of course, there’s the automatic Ubuntu every-six-month versions and Debians’ “when is 6.0 coming out? when it’s done.”
The highlight for me is support for the HTML 5 FileReader API and working D’n’D (under Linux).
Belive or not, it’s rendering pages three times faster than 5.x version