2

I have integrated my solution in to a continuous integration tfsbuild 2010 server. This works nicely building all my libraries.

Next I would like to increment the version number during each build on the CI server.

The makeup of the version number is: (Major version).(Minor version).(Revision number).(Build number)

My question is, what is the best practice as the number that should be incremented in this scenario? I would have thought the build number so that I end up with 1.1.1.123 and next check in results in 1.1.1.124 etc.

What I am wondering though when does the revision number get incremented? Major is manual for major releases, the minor version as I create multiple branches for releases.

Am I correct or what is the correct practice?

amateur
  • 43,371
  • 65
  • 192
  • 320

2 Answers2

2

For major, minor and revision, see "Semantic Versioning 2.0".

For a build for a similar set of feature, only the build number get incremented (if the build is successful, as Gonen comments below).
If not successful, the next build would reuse the same build number.

The revision number is also called "patch" number:

Patch version Z (x.y.Z | x > 0) MUST be incremented if only backwards compatible bug fixes are introduced.
A bug fix is defined as an internal change that fixes incorrect behavior.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Just to note that some build-systems allow you to increment the build-number only if it was successful, so if build '1.1.1.123' failed, the next build will use the same number, and the final release will NOT look like '1.1.1.984746753'... – Gonen Nov 05 '12 at 09:00
0

You can, not should increment only build number (less important part), I'll repeat @VonC

and add - it have sense only for published builds, for internal builds incrementing any numbers haven't sense from customer and developer POV

Lazy Badger
  • 94,711
  • 9
  • 78
  • 110