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 tools force developers to adopt a version scheme of a certain form, form instance "major.minor.build.revision", where each field must be a number.

How do I fit in betas in there? For instance, what version should I choose for version "2.0 beta2"? Should it be of the form "1.99.x.y" (it's not yet 2.0 stable) or "2.0.x.y" (2.0 beta introduces breaking changes with 1.x).

share|improve this question

3 Answers 3

If you are stuck with purely numeric revisions you could make odd minor revisions release betas for the corresponding major which has a even minor number, e.g.

Beta : 1.3.11.df41a

Release : 1.4.1.df41a

The beta for 2.0 could then be any of 1.9, 1.11, ...

share|improve this answer
    
This convention has been adopted by several high-profile Free/Open Source projects (e.g., the Linux kernel), so I'd strongly recommend at least considering it, on the basis that developers are likely to be familiar with it. –  Dave Sherohman Oct 7 '11 at 12:06

in the example of "major.minor.build.revision" we abandoned the revision number and use the latest to indicate a beta (where beta would mean "not fully tested"):

1.2.1.0 -> normal release
1.2.1.1 -> beta release

Now I hear you say "what?? no revision number? how do you track bugs then", as I know people/companies sometimes tend to match the "revision" number with their VCS especially when using svn. At least two options: get rid of the build number instead and keep the revision (do you really need more than major.minor for the actual version?), or what we do is tag the repository with the version number for each release which is the other way around but has the same effect + we feel clients shouldn't need to know what the amount of commits in a VCS is.

share|improve this answer
    
In your example, does the beta release 1.2.1.1 follow the normal release 1.2.1.0 or precede it? –  Joh Oct 7 '11 at 7:28
    
beta follows it, it would be really weird if a higher number would preced a lower one. 1.2.1.1 would be the beta for 1.2.2 or 1.3.0 –  stijn Oct 7 '11 at 7:36
    
What disturbs me a bit is that what we call "1.3 beta 2" is the 2nd beta that precedes 1.3. With your numbering scheme, it would be called "1.2.1.2". If I use "1.3.0.2" instead, I get the weird effect that "1.3.0.2" is before the final "1.3.0.0". –  Joh Oct 7 '11 at 9:00
    
that's true, but there's not really a lot of choice if you have to use numeric only.. Just pick a convention and stick to it. Customers don't care a lot about the numbers, so if everyone in the company knows what it means it's ok. –  stijn Oct 7 '11 at 9:24

You could modify the practice of Major.Minor.Build.Revision to something more like Major.Minor.Release.Revision. See examples:

1.0.0.0 - First Release

1.0.0.123 - Beta build approaching second release

1.0.1.0 - Next release

1.0.1.234 - Beta build approaching third release

1.1.0.0 - Third release

etc..

share|improve this answer
    
How do I know if 1.0.0.123 is the first, second... beta before 1.0.1.0? Moreover how do I distinguish between a bugfix release 1.0.1.1 and a beta of 1.0.2.0 ? –  Joh Oct 7 '11 at 9:03

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.