Currently, we have a versioning scheme following the major.minor.patch pattern. Development is done in a branch (i.e. - branches/b4_2); a release is a tag (tags/r4_2_0). To determine the version inside the code, we have a class which can parse the SCM URL (FooVersion.java). If the URL represents a branch, the SVN revision is appended (for QA builds).

We're re-evaluating versioning and, more pointedly, what sort of environments we have up. The big change here is adding the concept of a beta environment for our "super users". Along with this, I'm rethinking this potentially over-engineered version derivation system.

How do you determine, in the code, what the version of the software is? Creating a release is already a manual process (create tag, check in JARs for the related libraries we develop, etc.) which could probably be scripted, so is there a benefit to the way we do it over having a text file which is updated when a version is cut?

  • 1
    nvie.com/posts/a-successful-git-branching-model is git specific, but the workflow regarding versioning may be relevant/helpful.
    – Craige
    Commented Dec 12, 2011 at 18:44
  • 1
    That model is in my mind for when I can finally force the switch to git. That author mentions using files in SCM to track versions (which is part of what got me thinking about this). I'm sure switching our derivation technique to use git would be non-trivial, so that's another concern...
    – sarumont
    Commented Dec 12, 2011 at 18:55
  • Why not just use the SVN revision as the version?
    – user1249
    Commented Dec 12, 2011 at 18:55
  • At the very least, because that ship has sailed. I think I'd prefer users to see a date-based revision, as that is less likely to confuse them (version 10.11 -> 12.11 is friendlier than version 3142 -> 5321). Maybe for the (upcoming) redesign. This solves the automation issue, too, as the timestamp is essentially the build date (which is also inserted into FooVersion.java via ant substitutions) with some formatting.
    – sarumont
    Commented Dec 12, 2011 at 19:29

1 Answer 1


We distinguish between a build identifier (the SVN URL + revision, although this could be a git identifier as well) and a "marketing" version number, the latter managed in a text file and updated by hand.

There is very little use and some harm in having these two numbers depend upon one another. They are very rarely used together. There is a heavy n:1 relationship between SVN commits and marketing number increases. Users get confused when version numbers jump wildly. When you start shipping binaries together (like your related-libraries-JARs), you need a release identifier that is independent of binary identifiers. We, for example, combine 5 packages for a binary release, each of which needs a version identifier, so you can't derive your version number from any of these 5 URLs in any way.

Thus, I'd advise you to drop the version derivation scheme and manage the marketing version independently. Use the SVN URL+revision as a build identifier, put it in some remote menu in your software and in the error logs that are generated for bug report purposes, and never touch it programatically.

  • You're essentially reinforcing the thoughts I had prompting this question. :) Pulling the derivation out, I can pull the logic of the version class down. I'll probably have each "versionable project" extend it to provide name and dependencies (both fairly static) as well as the version identifier (updated manually). Cheers!
    – sarumont
    Commented Dec 14, 2011 at 18:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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