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.

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?

share|improve this question
1  
nvie.com/posts/a-successful-git-branching-model is git specific, but the workflow regarding versioning may be relevant/helpful. –  Craige Dec 12 '11 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 Dec 12 '11 at 18:55
    
Why not just use the SVN revision as the version? –  user1249 Dec 12 '11 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 Dec 12 '11 at 19:29

1 Answer 1

up vote 2 down vote accepted

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.

share|improve this answer
    
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 Dec 14 '11 at 18:06

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.