The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

How do versions work?

I'm wondering how software versions work. I guess everything before version 1.0 is the beta version, but after version 1.0, how do you decide if your next build is going to be 1.0.x, 1.1.0, or 1.1.x, and so on? Is there any specific way for determining the version??
Saturday, April 22, 2006
Heh, if only there was some sort of convention!  It really is up to you, but the most typical way for commercial software is (Major Version).(Minor Version), and some throw an extra number on there for even finer grained versioning.
Matt Secoske Send private email
Saturday, April 22, 2006
version systems depend on your development cycle. the first two numbers are known as the major and minor release number. the last number 1.0.0.x is generally a sequential build number.

beta versions can come after 1.0 too, when you have an ongoing beta program. recently I started using 1.0.x.0 where x is non-zero for a beta release, e.g. would be the full release, and would be a beta release. But if you want to give your beta the same major/minor as your upcoming full release you need to do it differently.
Ben Bryant
Saturday, April 22, 2006
It's mostly random.

Everybody has his own system, and it doesn't matter at all.

Some people increment their version numbers so they get more versions than the competition (version inflation). Other people use the release date as version number, that way people can easily see how old a release is by looking at the version.
L. Lort
Saturday, April 22, 2006
There's no official rule for this.  Someone just decides when to bump up the version number.

I strongly suggest that this decision not rest in the marketing department's hands (Windows "95", anyone?)

A lot of people are now using four-place version numbers:
<major>.<minor>.<revision>.<build>  (sometimes seen as <major>.<minor>.<build>.<revision>)

Good practice is to have nightly builds, where the <build> component of your version number will always be incrementing.  That way you can always identify where stuff got fixed.  When you ship a bug-fix to customers, you increment the <revision> part.

We reset our build numbers whenever the major or minor part changes.  This is because it becomes a different branch in the source control system, and enters into the maintenance part of it's lifecycle.

So we do it like:  -- Nightly build for 1.0  -- Nightly build for 1.0
  : -- Ships to customers  -- Nightly build for 1.1 -- new development branch is created -- Nightly build for 1.0 -- now in maintenance mode  -- Nightly build for 1.1 -- Bug fix for 1.0  -- Nightly build for 1.1 -- Nightly build for 1.0  -- Nightly build for 1.1

Your mileage may vary.
example Send private email
Saturday, April 22, 2006
Always assume that when the major version increments that things under the hood have changed quite a bit.  This is normally database changes, API's, data structures, etc.  This is often when the previous major version's API stops working.

Minor version increments are normally along the same lines but shouldn't break things *too* much.  API's may change/expand, but things are rarely deprecated.
KC Send private email
Saturday, April 22, 2006
What I do is 1.1 has some cool new, but minor features. 1.0.1 is bug fixes only. Lots of new features is either 1.5 or 2.0.
Saturday, April 22, 2006
The lesson I've learned:

Make your mind about the versioning before the project and consider multiple platforms and your tools and be frustrated anyway.


A Windows executable or DLL has a version number a.b.c.d so I decided to have major, minor, release and (increasing) build number:

the visual studio installer only supports a 3 number (a.b.c) scheme. So I have to increase c for every alpha release to QA.

so I came very fast to

And here comes Mac OSX: it supports a 3 digit(!) scheme, so 1.0.9 was valid but NOT 1.0.10 (also the release note
generator of the bug tracking system (not fogbugz ;-) )sorts 1.0.10 BEFORE 1.0.9)

So, at the final release we had to update the scheme and minize the mutability to 999 possibilities in complete.

That's how versions suck.
Husker Send private email
Sunday, April 23, 2006
I simply use the date as the version number (build number).

So the second build of April 24, 2006 would be
Frank de Groot Send private email
Monday, April 24, 2006
To complicate the things even more, versions are not necessary numbers. Take the following examples: XP, 2003 R2, Vista, .NET 2003. Debian is also notorious in this regard: Potato, Woody, Sid, Sarge...
smalltalk Send private email
Wednesday, April 26, 2006
I believe a pretty common approach indeed is


BugFix speaks for themselves, MinorVersion is usually when you add a feature, MajorVersion is done when major parts of the code are rewritten or design changes are part of the deal...

WinAMP uses fibonacci numbering for their versions, might be something for you too to confuse your clients... "For the last time, NO! We did not skip version 4, 6 and 7, we're using a pseudo-intellectual version numbering to look coooool!" :-)
Leon Mergen Send private email
Wednesday, April 26, 2006
It's worth separating the engineering version number from the marketing branding.  Hence, "Windows XP" is really NT 5.1, and "Vista" will be NT 6.0.

(If you don't like "Windows 95" then call it bad branding and not bad version numbering.  Personally, I don't think it's so bad, but eh.)

That way you can increment the version number when it makes sense in the codebase, track patch levels with dates, or ever-incrementing build numbers, or whatever.  And the customer only sees "Foo Quad-Deluxe R2" or whatever you want to brand it as.

If you're a small shop, you may find yourself doing both the engineering and the marketing, but at least think about the problem from both sides, and you'll often come up with different results.  Just keep some "branding" code in your codebase and you can control it separately from the source branches, etc.
mkale Send private email
Saturday, April 29, 2006
Well FWIW:

" Take the following examples: XP, 2003 R2, Vista, .NET 2003."

Type "ver" at the command prompt and you get:

Microsoft Windows XP [Version 5.1.2600]

Nate Send private email
Tuesday, May 02, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz