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 to increment Version/Build Numbers

I am trying to create a daily build process and have a basic question about incrementing version numbers.

I understand the Major.Minor.Revision concept behind the first 3 nodes of a version number, for example "4.0.15".  But I am slightly  confused the forth node, which I have always called the build number.  Does this build number ALWAYS accumulate, or does it get reset from time to time, and if so, when?

For example, if my current software is version 4.0.15.987 and begin work on version 4.1, should the version number for the first build be 4.1.0.0, or should I continue the build number and make it 4.1.0.988?  I had always been under the impression that build numbers always accumulated, but now I'm not so sure.

Wanted to get a general idea of what the industry standard was with regards to version/build numbers, so any input would be appreciated.

Thanks
PaulS
Thursday, September 01, 2005
 
 
Use the last number to refer to the number of your Subversion revision.

Then, at a glance, you can determine what codebase to pull in order to rebuild it from the ground up.  ;)
KC Send private email
Thursday, September 01, 2005
 
 
I have always seen then accumulate. Otherwise how could they uniquely indentify a build?

Release numbers are different though. I would encode a build number in a release version, though I would include it in the package attributes somewhere.
son of parnas
Thursday, September 01, 2005
 
 
I usually have the build numbers follow the release when it is branched, and reset the build number to 1 on the main line.

This is one of those toolsmith build/release questions that I couldn't find any discussion about a few years ago. So I wrote a book "Practical Development Environments", which discusses this topic, and many other tools-related questions. O'Reilly are publishing it at the end of September, with goldfish on the new-style cover.

http://www.oreilly.com/catalog/practicalde

~Matt
Matt Doar Send private email
Thursday, September 01, 2005
 
 
Actually, the Subversion revision number sounds like a good idea. Any idea how NAnt could do that? Being too lazy to think here.
el
Friday, September 02, 2005
 
 
I'm a fan of incrementing the "build number" every time the product is built, and resetting to 0 any time one of the others gets changed. I'ld suggest that all developers send code to a central build server where the release gets built and then distributed to testers or wherever and only increment the build on that server.  (Largely because the developer may build a dozen times while fixing stuff before committing their work, and with more than one developer the 'build number' becomes a resource that can only be safely owned at one place at a time.)

Sunday, September 04, 2005
 
 
Use Ant - look up the BuildNumber task:
BuildNumber
Description
This is a basic task that can be used to track build numbers.

It will first attempt to read a build number from a file (by default, build.number in the current directory), then set the property build.number to the value that was read in (or to 0, if no such value). It will then increment the number by one and write it back out to the file. (See the PropertyFile task if you need finer control over things such as the property name or the number format.)


http://ant.apache.org/manual/index.html
Use Ant and don't look back
Sunday, September 04, 2005
 
 
I'm not so much a fan of using the checkin # like the subversion revision number.  What happens if four people are working on code that day, and you all commit.  Then, the subversion # would be incremented by 4 from one build to the next, and what happens if someone doesn't know that and get source to an intermediate revision?

Why not just tag every build with a unique incrementing #, then you can pull the code from any build by getting the tag.

Personally, I like to reset the build # back to 1 whenever any of the other numbers change, but that's mostly an asthetic thing I suspect.
Michael Kale Send private email
Thursday, September 08, 2005
 
 

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

Other recent topics Other recent topics
 
Powered by FogBugz