Adam, what version number is your emacs?
âUsers donât care about version numbers.â
I did telephone tech support for a year or so, and I wish I had a nickel for every user who said something like âIâm having trouble with my Windows 97.â Users donât care about anything that isnât directly connected to the task theyâre trying to accomplish. Long, complicated version numbers at least force people to look them up instead of guessing.
Microsoft doesnât have a strategy of using dates in product names; they have a strategy of isolating the marketing departmentâs pointless, random name-changes (NT, 2000, XP, Vista) from the engineering version numbers.
If you want dates in a versioning scheme, why not just plain-old dates? Why encode them in some way that makes them harder to read?
RubyGems proposes a rational version numbering policy (see a href="http://rubygems.org/read/chapter/7)"http://rubygems.org/read/chapter/7)/a which helps users easily determine when to upgrade and what kinds of changes are present in a release. IMHO, this system is far more useful than using years and months for the version number, like âWindows 95â, because that does not provide any insight about the significance of changes present in a release.
Iâm glad I live in the Open Source world, where we have a little bit more respect for usersâ intelligence. Dumbing everything down will not help you in the long run, Proprietary world!
News flash: arrogance isnât helpful either.
Heh. I donât use Emacs.
Anyway, nice try, but no cigar. The version that I would install if I wanted it would be 21.4, but this is actually version 1.21.4. After version 1.12 the authors realised that theyâd never need to do an incompatible version 2, and just dropped the major version altogether. The Emacs version scheme is just {minor}.{patch}
Vim (which I do use) is on version 7, which again is getting a bit high. Although Vim never had a version 2, so itâs really version 6, this is still on the high side; but then no all OSS projects are that good; just a lot of them.
We identify tons of consumer products using a simple model year designator.
In the United States, yes. Here in Europe, no. Windows 95 was our first year-based model designation, and it felt decidedly odd. I still canât think of a single consumer product I own that uses years. Itâs all CD620, E-500 and ML-1610. O wait, I still have an installed copy of Windows 98 somewhere, but thatâs really it. Cars donât even have model years here.
My experience is vastly different from the original post.
Confusion come because there are two aspects in version numbers: the engineering side, and the marketing side.
The engineering side versions number needs to be accurate and use a very coherent scheme (ie: should not change every year of so). In the opposite, marketing version schemes HAVE to change (because change generates interest).
(If you donât beleive me:
Windows 3.11 = 95A = 95B = 98 = 98SE = ME,
Windows NT4.0 = 2000 = XP = Vista
Sybase 4.2 = Sybase 10 = Sybase Adaptative Server Anywhere
Illustrator 1.0 = Illustrator 88
)
Companies with strong engineering culture can end up consitently using engineering version in marketing [Coherent numbering from Mac OS 5 = Mac OS 9, Or from NeXTstep 0.9 to OPENSTEP 4.2]
Companies generally have two different naming scheme for the internal and external aspect (But, in companies/projects with crappy marketing, the marketing takes the engineering version numbers, and present them directly to the customer. After a while, there is pressure from marketing to engineering to manipulate version numbers, at which points nobody understand what you are talking about internally or externally. Firefox is a good example of that, with a random 1.5 version poping out of nowhere, or a 2.0 that is perceived as a minor upgrade).
Sane companies have a coherent, consistent and immutable naming for eng version numbers. The most common way of internal numbering is
MAJOR.MINOR.REVISION.BUILD
MAJOR means compatibility is broken in some way by a big architectural change
MINOR means another version of a MAJOR branch, with support
REVISION is a stepping number for patch level
BUILD is an unique identifier to avoid having two identically named but different versions out there. Sometimes it is as simple as a sequential number, sometimes, it contains the build date in it.
MAJOR.MINOR define a release from which marketing numbers are derived.
Common marketing numbering scheme are:
- Directly using MAJOR.MINOR (very common in engineering driven companies, but can lead to pressure from marketing = engineering)
- Re-inventing an incremental number on top of MAJOR.MINOR, so, from the outside the product have version 1, 2, 3, 4, 5 etc.
- Mapping MAJOR.MINOR to an ordered sequence (â2000â, â2003â, â2005â or â95Aâ, â95Bâ or âDapper Drakeâ, âEdgy Eftâ)
- Mapping MAJOR.MINOR to an arbitrary string (âXPâ, âVistaâ or âPantherâ, âTigerâ)
(It is somewhat interesting to see that, as the industry matured, the marketing schemes went from close to eng, to the most free form one)
[And donât get me started on individual component numbering :-)]
Whatever you do, make your version numbers sort right, at least in your internal systems. (Use Windows 1995 instead of 95)
Donât write
2007-Feb-17, or 02-17-2007, instead write
2007.02.17
It makes life a lot easier.
What about the competitive marketing aspect? Version numbers often also communicate how mature a product is.
Would you rather buy WordProcessor Pro 1.0 or WordMuncher 9.5?
Of course since there is no authority on version numbering there was a lot of cheating and starting with version 3.0 for the first release.
so have you ever used CI?
on my last project we were building a new version of the software wroughly every 2 minutes. We wanted to know which was the more recent that we could pass to QA at any one point. what easier internal way than saying version 21 or version 207 for that matter.
I agree that this is useless to a user but to internal teams incrementing a build number is incredibly simple to implement and can be read by anyone on the team.
If you use dates, how do you seperate bugfix releases from new versions? For instance, Im happing running 0.3.5; and I dont want to upgrade to the hottest/latest/wowest 0.4.0 as it will break my current setup (new configuration, etc) and I dont care about the new features as I want stability not features. Then when a new bugfix is released 0.3.6, Im going to use that one.
How is that solved when only using build dates?
Brian:
âFor example, 20070102, putting whatever decimal points you want in there. Is that January 2, 2007, or February 1, 2007? This can lead to confusion as wellâŚâ
Did you notice that neither the EU and US standards start with the year? Therefore, weâre dealing with either Twentyember 7, 102 (US) or July 20, 102 (EU).
Jeff said: Even then, Iâd prefer âFirefox 2007 (October)â over âFirefox 2.0.5â because it conveys more information, and itâs easier to understand.
It isnât conveying more information, thereâs important information missing from your version examples above. Here are the last four Firefox release dates and their version numbers:
December 19, 2006 (1.5.0.9)
December 19, 2006 (2.0.0.1)
November 7, 2006 (1.5.0.8)
October 24, 2006 (2.0)
September 14, 2006 (1.5.0.7)
Would you really want to release a âFirefox 2006 (October)â and then a âFirefox 2006 (November)â which wasnât an upgrade from the October version? How would the two âFirefox 2006 (December)â versions be distinguished?
Non-consumer software can stay static for months or even years, leaving a customer with say a 2002 version which is actually perfectly current and yet he is dissatified that his software is âout of dateâ because it is not called â2007â. You could end up having to release the same thing just with an updated date to keep that sort of customer happy.
To put it another way, you are committing to keeping the product up to date with new releases every month or year, depending on how you named it.
Let marketing do whatever they want to do. Their wants and needs are quite different. At our company marketing want to use years for marketing purposes. Our products are fairly large and it takes many years before a new major release happens. I guess they found that having the year as a part of the name helps the customer remember how old a version they are running :). Sometimes they want the year to bump, even though only a service-pack has been added. Is that bad you say? Well, I canât stop them. That is their domain, their business.
Keep version-numbers for tech-reasons:
Major version - a number. Minor version - a number too (service-pack) 6.0, 6.1 6.2 etc. Major versions are planned. Minor versions are sometimes planned, and sometimes the content come up due to change requests, bugs or similar. Sometimes, while building our software though, we run into a situation were we need to push a hotfix. This is also a number. A hotfix is not a planned activity and no-one really plans for them. However - they are indeed sometimes needed, unfortunately. We now bump the software to i.e. 6.2.1. A hotfix is the smallest increment that we ever release externally, but internally during testing we still need more.
And now the date comes into play. The date is helpful for testers and developers on short-term basis during testing. It is easy to see the age of the build being tested/used. Since the preferred revision control system also has atomic check-in version-numbers, it makes sense to apply it to the version-number. because, then it is easy for a developer to work on the exact code that provoked a bug, for example.
So, to sum up:
External - Internal
6.0.0 - 6.0.0.2006.10.01.12334
6.1.0 - 6.1.0.2006.12.24.12422
6.2.0 - 6.2.0.2007.02.10.12468
6.2.1 - 6.2.1.2007.02.19.12492
Major.Minor(Service-pack).Revision(Hotfix).Year.Month.Day.Changeset
All numbers - all sortable
Using this, we can see if the app has been through major changes, service-packs, hotfixes, dates for testing (short-term), and the changeset number (to use for fixing bugs, for instance). Also, since the changeset# is specified, there is no longer any need for labeling the source code in the revision control system (except for external releases). You may want to make sure that the version-number on the dog-tag is kept to major.minor.revision for the externally released versions (as shown above), and use the date+changeset only for the internal releases.
And, like I said: Let marketing do whatever they want to. They wanna use a fancy schmancy scheme? Sure, good for them. But the dog-tag is for tech-use, and should help the techies. And I can i.e. easily pinpoint that they lack an important hotfix, by looking at the hotfix-specifier. Sure, I could now use the changeset-number (if in the released version-number) or the date to figure this out. But that would require maintaining a separate list somewhere. I find that getting rid of that extra information to be a good trade off for the customers. It is easy for the customer to relay those three numbers upon enquiry. These three numbers doesnât say much to most users, but it isnât important for them anyway. They would only see this if they were particularly interested in it (in which case they might have the motivation to understand too) or if they need tech-support.
Always interesting reading in your column Jeff
Regards,
Ronny
We always had 2 build numbers. One for users, the other for testers and developers.
Users just care that We have App Version 3.8. A point release was some minor functionality, but the reality is that these things were decided by outside the dev team so we just lop that on to the start. The basic rationale was âlots of stuff = major release, some stuff = minor releaseâ and also, because it was a big company, a major release cost more to push to production hence everything was a minor release until they could no longer bluff âjust a trivial changeâ. Again, thatâs the politics part and we all could care less.
Itâs a web app, so compatability with previous versions isnât an issue.
Internally, we ran continuous integration and did daily builds for testing. We labelled builds using the same technique the .net framework internal build numbering uses.
2.0.50727.42 which is saying.
version 2.0
(200)5 July 27th
build 42
Here because we prepend the âexternalâ version to the build, the century part of the date is moot and dropped. Itâs better to have the 5 unchanging (meaning 2005) but the year could be dropped entirely. (donât drop it if youâre unfortunate enough to have to develop the same version for over a year)
The reason this is useful for dev and test is timestamps on files can be changed too easily so theyâre not trusted, but we can inspect the version from code. We inject the build number into all the code when it gets compiled from a nAnt script, and use that same version as a tag to source control. We altered this slightly by putting .hhmm as the last bit because again, it was more meaningful to us as we would sometimes kick off a new daily build mid-day during a qa cycle and to verify they put the correct version in production. We also archived all the source, list of changes, etc into a folder structure based on this same trivially computable version.
As other posters said, knowing that someone is using last weeks build of 1.0.70217.1642 is more meaningful that build 7223 even when 7223 is computed in a similar manner. Being easy for me to trivially compute using just my own wetware (or some broken script language) is a big bonus and even non-tech people can clue in when theyâre ready.
For most people (and users), they stop reading after 1.0 unless specifically asked by someone so they, for the most part, donât notice.
em"We brought it on ourselves by letting our geeky, meaningless little construct of major and minor version numbers spill over into pop culture. Itâs not worth it. Letâs reel it back in."/em
Related to pop culture, itâs probably not possible to reel it back in. Version numbering is now akin to progress. We see this with Web 2.0 and all the rest. This links in with the marketing comment above. Version numbers have different audiences who use them for different purposes. The goal then is to work it in a way that the multiple needs can be met without creating SID 6.7!
âIf you install some software and it is 0.9.13 you know it is beta. If you install 1.0.0 you know it is final versionâŚâ
Yeah right! Sometimes open source projects release their final, definitive version and not only freeze, but also fossilize, the development at something like 0.6.953. Maybe they have a 1.0-phobia.
I say: let the first wide public release be 1.0. No one trusts anything.0 anyway. After that feel free to bump the first number every year, or if you expect less frequent major breaking of everything, do it then.
Aaron OK, point to 3 bits of software which, when compiled on Linux 2.0, will fail to run without a recompile on Linux 2.6.20
Iâm going to have fun actually testing that one outâŚ
Also read the first paragraph of Greg Kroah-Hartmanâs kernel-device driver âStable API Nonsenseâ[0] document for the actual position of the kernel developers on the kernel-user interface; it is stable, and there is a claim of binaries compiled for 0.9 still running on 2.6
Version numbers by year are simply copying the auto trend which is both annoying and insulting.