Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Some projects bump version before kicking off a new development, while the other projects bump version when tagging a release.

Which approach is better?

If version number not changed at the start of new phase, the developers may forget to change it and simply release the program.

If version number changed before tagging release, then 2 the version numbers (tag and Makefile/AssemblyInfo.cs) do not match.

git describe may give you v1.2.3.4-15-g1234567 if current revision is after v1.2.3.4, but you have already changed the files to have v1.2.3.5

share|improve this question
add comment

2 Answers

When using four-segment version numbers like .NET assemblies have, I prefer using a version control tag to set the first three segments, then the fourth segment is the number of commits since that tag.

For example, a version gets tagged "v1.2.3". If git-describe returns "v1.2.3-4-g1a2b3c4", then when built that assembly gets versioned as 1.2.3.4.

If a tag is later applied to that version, then git-describe will return "v1.2.4" instead, which represents version 1.2.4.0. The next commit would then be 1.2.4.1.

The benefits I find from this system are:

  • Every commit automatically increments the version number.
  • A version can be made a ".0" release by simply tagging it.
  • Though not perfect, this system works with DVCS because it counts the number of commits since the most recent tag.
share|improve this answer
add comment

The main reason for version number is there so that when a bug is discovered you are able to debug using the actual version of the source code that the error actually happened in (thus discover the real reason for the bug).

It does not matter what versioning scheme you use as long as the user of your produce can communicate to the developer enough information so that the developer can achieve this goal.

Other reasons for versioning are for marketing and help (sometimes legal) teams.
These teams have their own priority's for versioning.

  • Help
    Wants an easy way to determine compatibility and features and potentially stability (see Linux Odd/Even number scheme).
  • Marketing
    Wants a bigger number each time (preferably above 2)
  • Legal
    Wants to make sure you have all features committed to before increasing the number.

In all cases the scheme used is unimportant. As long as you are consistent (or have easily available highly detailed documentation on changes in meaning).

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.