Where does the version number come from?

Question

I have a version control system (e.g. Subversion) and now I'd like to set up a build process. Now I have to create a version number and insert it into the system. But where does the version number come from and get into? Assume I want to use this common <major>.<minor>.<bugfix/revision> scheme. Should I pass a number to the build script? Or should I pass arguments like increaseMajor, increaseMinor, increaseRevision? Or would you recommend to create a branch with the number which will be detected by the build script?

I could imagine that the major and minor version number have to be put in manually somewhere. The revision number could be increased automaically. But still I don't know where I would place the major and minor number.

In my case I have some php files that I would like to zip, but before I have to insert some version numbers into php file.

---

I have edited this post to try to make my request clearer:

I do not use Subversion, that was just an example. And I don't want to discuss the version number scheme.

Imagine I want to create version 3.5.0 or 3.5.1. Would I pass this version number to a build script? Would the script create the branch in the repository with this number or would it expect that someone has already created this branch? Manually? Or would the build script look for name of the branch (e.g. '3.5.1) and use it for further things? And does the version number come from my brain or is it automatically created (I guess the major/minor number it comes from my little brain and revision number is created)? Or would you place the number into a file that may gets inserted into the repository?

I guess if would use a release management tool I would insert the version number there. But I don't use one yet.

Answer 1

For subversion, either take the global revision number and use that as "build" number or, even better, don't rely on it at all and manage versions with tags and/or branches. The main problem with the global revision is exactly that, it is global to the repo. It will increase even though some parts of the repo don't change.

Completely disassociate versions from the repo's revisions is IMHO better. You have tags, use them.

Answer 2

The revision in svn or any other version control system is not the same thing as your product release number (or even your build number).

There are any number of ways that you can enforce the version number. Commonly in subversion you can create a branch (or tag, they are essentially the same thing) for a build and if this is a release version you create a tag for this eg svn://my-repo/releases/1.0.0

You could either pass a parameter into your build script to get the code and use that as the build number, or have a directory which your build script used, and svn switch this to the branch that you wanted to build, the script could use svn info to determine what version it was building.

Answer 3

x.y.i.j

Where x - Major version, y - Minor version, i - Build number, j - Revision number

Major version increments on major changes (new architecture, new UI, etc)

Minor version increments on minor changes (performance improvement, major bug fixing, etc),

Build number increments everytime you makes a public release.

Revision number increments everytime you commits changes to the project source tree.

I prefer to point 0 as revision number into AssemblyInfo.cs and point the real number in the name of release package (foo-1.1.7.110-source.zip)

Answer 4

agreed with all previous on the use of branches and tags. Additionaly the branch names and tag names can be incorporated into a build process w/ some clever scripting.

The only tidbit I wish to add is that you should sneak your SVN revision into every build. Sometimes it's easily to get back to a certain point w/ the revision instead of knowing the tag or branch. 99% the tag/branch is good enough, but the revision is great for incremental/internal/continous/test builds.

Answer 5

All branches should be created manually. The build script should work off a tag and/or branch, starting with checking it out (or may be updating it). As part of teh build process, it's a good idea to create a tag on the exact snapshot that gets built.

You would normally have build number and a version. Build number can be incremented automatically and checked into version control as part of the build (except for tag-based build, where the build number has to stay outside of repository - another reason to avoid tag-based builds).

Version is usually stored in a file that you update manually once per release cycle. It's checked into th eright branch and then left alone. For example, the mainline would have version = "3" in its file, the first revision on release branch would have version = "3.5", and if a patch release becomes needed, you branch that off your release branch and check in version = "3.5.1"