How do you version your projects?

Question

I understand that Microsoft uses this template when versioning their products: Major.Minor.Build.Revision.

Major is changed when the "developers" want to show that there is a big change in the software and backward compatibility cannot be assumed. Maybe a major rewrite of the code is done.

Minor number represents a significant enhancement with the intention of backward compatibility.

Build number is a small change, for example a recompilation of the same source.

Revision is used to fix a security hole and should be fully interchangeable. Both Build and Revision are optional. This information is based on MSDN Version Class.

How do you version your projects and why do you version them this way?

Answer 1

I use major.minor.point.revision, where point is a bugfix-only release and revision is the repository revision. It's easy and works well.

Answer 2

We generally do major.minor[.maintenance[.build]] where I work, but it seems to vary a little per project.

Major/minor the same as you mentioned. maintenance would be incremented for small (bug) fixes and build for each time the build server runs.

Answer 3

See this: SO version number question

Answer 4

I just do Major.minor. Since I'm a single developer (with occasional help) working on a web app most people couldn't care less about the minor fixes that I make. So I just iterate up the minor versions as I put in new features and major version numbers when I make some whopper of a change/upgrade. Otherwise, I just ignore the small fixes as far as version numbers go (though I do have Subversion revision numbers if I need to refer back for myself).

Answer 5

I work on a lot of smaller projects and i have personally found this useful.

PatchNumber.DateMonthYear

This is for small web based tools where the users can see when the last update and how often it has been updated.

PatchNumber is the number of releases that has been done and the rest is used to show the users when this was published.

Answer 6

I often see Xyz where X is the year after release number and yz is the month of the year. I.e. 201 is January, 2 years after release. I.e. when product launches in May, it's first release number is 105. Release in February next year is 202.

Answer 7

We usually version our projects based on the current release date, YYYY.MM.DD.*, and we let the build number generate automatically, so for example, if we had a release today it would be 2008.9.26.BUILD.

Answer 8

I just have a number. First release is 001. Second release's third beta is 002b3, and so on. This is just for personal stuff mind, I don't actually have anything 'released' at the moment, so this is all theory.

Answer 9

I personally like to use a scheme that focuses on the level of backwards compatibility that users of the project/product can expect:

Before 1.0:

• 0.0.1 = First release
• 0.-.X = Backwards compatible update
• 0.X.0 = Backwards incompatible update

After 1.0:

• -.-.X = Update without interface changes
• -.X.0 = Update with backwards compatible interface additions
• X.0.0 = Backwards incompatible update

Using compatibility as the central point in the version number makes it easier for users, especially if te product is a library, to judge whether or not they can expect a smoothe and safe upgrade or not.

Answer 10

Major.minor.patch.build with patch being the hotfix or patch release.

If you can get QA to by in and are on SVN, you could use the svn HEAD revision as the build number. In that way, each build describes where it came from in terms of source control and what's in the build. This does mean that you'll have builds that go up with gaps (1.0.0.1, 1.0.0.34....)

Answer 11

I started using a pseudo-similar format as Ubuntu: Y.MMDD

This helps for a few reasons:

• it's easier to check for version requirements: if (version < 8.0901) die/exit/etc.;
• it can be auto-generated in your build process

On that 2nd point (ruby & rake):

def serial(t)
   t = Time.now.utc if not t.instance_of?(Time)
   t.strftime("%Y").to_i - 2000 + t.strftime("0.%m%d").to_f
end

serial(Time.now)     #=> 8.0926
serial(Time.now.utc) #=> 8.0927

NOTE: t.strftime("%Y.%m%d").to_f - 2000 runs into floating point inaccuracies: 8.09269999999992

Answer 12

Major.Minor.BugFix.SVNRevision

e.g: 3.5.2.31578

• The SVN Revision gives you the very exact peace of code sent to the customer. You are absolutely sure if that bugfix was there or not.
• It also helps finding the proper PDB in the event you have an application error. Just match the SVN Revisions on your build server, copy the PDB to EXE location, open the debugger and you got the crash stack trace.

Answer 13

I used to like the Nantucket way of versioning their Clipper compiler in the 80's:

Clipper Winter 1984
Clipper Summer 1985
Clipper Winter 1985
Clipper Autumn 1986
Clipper Summer 1987

Oh and overlays....

[gets teary eyed]