27

I generally agree that major versions of a program should be 1.0, 2.0, ... and significant updates should be: 1.1, 1.2, ..., and that bug fixes should be at the third level: 1.0.1, 1.0.2, ... 1.0.156 (if you've been plagued by that many bug-fix releases between versions).

But now I want to release my first Beta that will be one of a series of Betas leading towards the release of version 1.0.

Specifically, it doesn't make sense to me, to number my Beta releases greater than the number I am developing to, e.g. 1.0.1 up to 1.0.15 (if I have 15 beta releases) and then follow it with 1.0.

But using numbers less than 1.0 seems awkward, e.g. 0.9.1 ... 0.9.15 and will cause confusion if I start using 1.9.1 ... 1.9.15 as the Betas for version 2.0.

Related:

How to do version numbers?

Just for information, after your help and great links with more info, this is what I decided on.

I've been going 0.7, 0.8, 0.9, 0.91 ... up to 0.98 for my alpha versions.

I know I can do 1.0 beta 1, which is the "standard" way. But taking everything into account, I'm going to go with: 0.99 beta 1, 0.99 beta 2 ... before I get to my 1.0 release.

If I do a pre-release of my 2.0 version, I'll probably then follow the pattern and call it 1.99 beta 1, 1.99 beta 2, etc.

Hopefully this question and the answers will help you decide on your scheme.

Community
  • 1
  • 1
lkessler
  • 19,819
  • 36
  • 132
  • 203
  • 7
    The one problem I see is that you've basically locked out all the purely numerical choices. You say that beta release numbers higher than your version number are nonsense, and beta release numbers lower than your version number are awkward. So that's all the numerical choices. The way I see it, you should just stick a "b" on the end. – jprete Sep 21 '09 at 21:01
  • jprete: that would be a good answer ... if the question opens again. – lkessler Sep 21 '09 at 21:12

6 Answers6

29

I think you should seperate out your version numbering from the status of the release.

Betas should always have "beta" after the version. Users should not have to reverse engineer your numbering scheme to determine the stability of the release.

So leading up to version 1.0 you should have 1.0 beta 1, 1.0 beta 2 etc. That gives users a clearer idea of what major release a beta is leading towards and avoids confusion with any maintainance releases you might put out in the meantime.

The important thing is that you need to distiguish between a bugfix release (which should increase stability) and a beta (which may decrease stability).

ctford
  • 7,189
  • 4
  • 34
  • 51
  • 1
    +1 Totally agree. Simple and yet so powerful that any user understand exact what is going on. – Stefan Sep 21 '09 at 22:38
  • That does seem "best" to me as well, and I'll give you the correct answer for it. My only problem doing that is because Delphi uses the 1.N.N.N scheme of numbering and will not allow "1.0 beta N". So I still have to dream up something. – lkessler Sep 22 '09 at 04:38
5

If you're using an old version of Semantic Versioning, (from before 2011-03-27), this section is relevant:

A special version number MAY be denoted by appending an arbitrary string immediately following the patch version. The string MUST be comprised of only alphanumerics plus dash [0-9A-Za-z-] and MUST begin with an alpha character [A-Za-z]. Special versions satisfy but have a lower precedence than the associated normal version. Precedence SHOULD be determined by lexicographic ASCII sort order. For instance: 1.0.0beta1 < 1.0.0beta2 < 1.0.0.

Joel Purra
  • 24,294
  • 8
  • 60
  • 60
Xiong Chiamiov
  • 13,076
  • 9
  • 63
  • 101
  • 3
    [SemVer has been updated to 2.0.0](http://semver.org/spec/v2.0.0.html), and now pre-releases need a dash to separate the extension from the version number: [`x.y.z-`, where pre-release is a dot-separated alpha-numeric identifier](https://github.com/mojombo/semver/blob/master/semver.md#backusnaur-form-grammar-for-valid-semver-versions). – Joel Purra Nov 28 '13 at 18:59
4

Version numbers are totally up to you. You could call them after animals or city names or use numbers.

Many projects wonder what to do with beta numbers for next gen software (2.0, 3.0 etc)

And whatever you do, just remember that you can do whatever you want to. Since version numbers are a marketing thing. It's just for users to see where in the process this version is.

So calling it 2.0 Beta 1, Beta 2 etc would work fine and the most important thing. The users would understand.

Ólafur Waage
  • 68,817
  • 22
  • 142
  • 198
4

One very practical solution is naming your testing iterations by release numbers (e.g. My Awesome App r1392).

Apple, Microsoft and many others do this for their internal revisions and only issue "real" version numbers for version pushed to their customers.

Gabriel Hurley
  • 39,690
  • 13
  • 62
  • 88
1

I would consider beta releases to be minor revisions to the "zero'th" version of the application so beta 1 would be 0.1, beta 2 would be 0.2. and so on.

Andrew Hare
  • 344,730
  • 71
  • 640
  • 635
  • 8
    What if you are releasing the "beta" of the next version (AKA, you're developing version 2.0 and you have already released version 1.0). This wouldn't work. – JasCav Sep 21 '09 at 20:30
1

1.2.3 - Where "1" is major version releases, not beta beta would be pre 1.0, the "2" would be major releases including new features, the "3" is minor releases. If you like you can append another after that that can be like your version control's commit id or something... but i shy away from that.

JP Silvashy
  • 46,977
  • 48
  • 149
  • 227
  • 1
    My alpha is already up to 0.98.9. I started running out of numbers. I guess I could use 0.99.xxx, but then I get stuck if I want to release a Beta for versions 1.1 or 1.2 or 2.0. I hope, by this question, someone might have an interesting idea on this. – lkessler Sep 21 '09 at 20:34