6

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).

Improve this question

3 Answers 3

Reset to default
2

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, ...

Improve this answer
1
  • 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, 2011 at 12:06
1

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.

Improve this answer
4
  • 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, 2011 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, 2011 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, 2011 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, 2011 at 9:24
0

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..

Improve this answer
1
  • 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, 2011 at 9:03

Your Answer

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

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