Fog Creek Software
Discussion Board

When do you update Revision/Build numbers?

I think I'm going to answer my own question, but I'm wondering when you other folks update your Revision and Build Versioning numbers. 

I don't currenlty use the Build number as I don't really see the need.  I'm the only developer at my company, and I don't use automated builds or an independent QA/Testing department.  So I don't really see the need to track every single build.  I could see a reason to in larger dev environments with more automation.

I have been using the Revision number to track minor fixes/upgrades to existing functionality.

The Major/Minor numbers are easier in that you are usually tracking functional differences in your code.

This seems logical to me, but I always like to hear from the greater collective.  You guys/gals always think of more things than I alone can.

Tuesday, August 24, 2004

Any time somebody other than a single developer sees a build, it should be numbered.

Flamebait Sr.
Tuesday, August 24, 2004

My longsuffering tester (Ms Trollop) insists I reply to this.

If it happens naturally in your IDE, let it increment, that's what it's for. If it doesn't, make it happen.

Relying on file datestamps (when you are jumping around in time to test things) can lead to tears and no bedtime.
ditto relying on comments in make or sourcefiles. Ditto file diffs. Ditto filesize.

Even if you aren't even slightly disorganised, distracted or dyslectic you will learn to love build numbers.  (you don't HAVE to show them to anyone else).

If you must, reset them on version bumps.

Tuesday, August 24, 2004

I increment my build number as often as possible. The build tool Ant has a nice little feature to handle this, and I see no harm in using it on every build.

Better to increment the build number too often than not enough.

I am also working solo on a project, so when I build locally it is THE build.

On the user interface (web application) in little grey letters at the bottom of the page the build number and build date are shown. It's easy to do, causes no harm, and makes life a bit easier.

Herr Herr
Wednesday, August 25, 2004

Build numbers are very simple.

Do a daily build, automated, overnight every day.

Increment the build number on each daily build.

And if you don't do a daily build, that's probably the first thing to fix.

This method is nice and simple, and ensures that every build has a unique number. Bonus points for tagging each daily build so you can reconstruct good builds later.

Revision numbers are a more political issue, it really depends on your organisational structure. I've wound up with an internal revision numbering scheme mapping onto more than one external revision numbering scheme for a widely-used set of libraries before.

Wednesday, August 25, 2004

Just use dates.

Mr Jack
Wednesday, August 25, 2004

No point in learning from other peoples mistakes, like the ctl3d.dll fiasco a couple years back, almost all of the versions of that dll had the same rev number and date, about all that you could do to figure out which of 5,000,000 different versions you got was the number of bytes. This one dll generated the phrase "dll hell."

I prefer to increment the build number each time I compile. Revision numbers (major and minor) tend to be driven by marketing: omg! its version 3! followed by version 5! followed by version 95! followed by version 8!

Wednesday, August 25, 2004


Ditto -- I had no end of "dll hell" with that one.

Sgt. Sausage
Wednesday, August 25, 2004

Agree with daily builds/increment build numbers frequently. Also, it's important to separate out the program version numbers from some "marketing" version number. If the marketing guys decide at the last minute to name your product after the year, keep your existing versions numbers and just add the marketing.

For example, AutoCAD 2000 is version 15, 2000i is 15.1, 2004 is 16 and so on.

Miles Archer
Wednesday, August 25, 2004

*  Recent Topics

*  Fog Creek Home