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

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.