11

I'm currently writing a small desktop application for a friend, but I'm doing it primarily as a learning experience for myself. In the spirit of getting educated and doing things The Right Way, I want to have version numbers for this app.

My research brought up these related results

but none of them address numbering of alphas, betas, release candidates, &c. What are the conventions for version numbers below 1.0? I know they can go on for some time; for example, PuTTY has been around for at least a decade and is still only at version beta 0.60.

Community
  • 1
Pops
  • 4,093
  • 4
  • 28
  • 41

6 Answers6

30

It really depends on the project; some projects don't even release a version 1.0.

The developers of MAME do not intend to release a version 1.0 of their emulator program. The argument is that it will never be truly "finished" because there will always be more arcade games. Version 0.99 was simply followed by version 0.100 (minor version 100 > 99). In a similar fashion Xfire 1.99 was followed by 1.100. After 6 years of development, eMule has not even reached version 0.50 yet. Software versioning at Wikipedia

One popular method of numbering versions (that I've started to use) is Semantic Versioning.

Under this scheme, version numbers and the way they change convey meaning about the underlying code and what has been modified from one version to the next.

Some quotes to give you more ideas on how it works and/or answer some of your questions:

How do I know when to release 1.0.0?

If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you're worrying a lot about backwards compatibility, you should probably already be 1.0.0.

Doesn't this discourage rapid development and fast iteration?

Major version zero is all about rapid development. If you're changing the API every day you should either still be in version 0.x.x or on a separate development branch working on the next major version.

If even the tiniest backwards incompatible changes to the public API require a major version bump, won't I end up at version 42.0.0 very rapidly?

This is a question of responsible development and foresight. Incompatible changes should not be introduced lightly to software that has a lot of dependent code. The cost that must be incurred to upgrade can be significant. Having to bump major versions to release incompatible changes means you'll think through the impact of your changes, and evaluate the cost/benefit ratio involved.

There are also rules on how to specify "alpha," "beta," etc. releases. Check out the details at http://semver.org/.

[Edit] Another interesting version numbering scheme is the one MongoDB uses:

MongoDB uses the odd-numbered versions for development releases.

There are 3 numbers in a MongoDB version: A.B.C

  • A is the major version. This will rarely change and signify very large changes
  • B is the release number. This will include many changes including features and things that possible break backwards compatibility. Even Bs will be stable branches, and odd Bs will be development.
  • C is the revision number and will be used for bugs and security issues.

For example:

  • 1.0.0 : first GA release
  • 1.0.x : bug fixes to 1.0.x - highly recommended to upgrade, very little risk
  • 1.1.x : development release. this will include new features that are not fully finished, and works in progress. Some things may be different than 1.0
  • 1.2.x : second GA release. this will be the culmination of the 1.1.x release.
Michelle Tilley
  • 1,229
  • 9
  • 17
1

I don't think there's a "standard" as such.

There is a convention for Release Candidates which is usually "[version] RC 1" etc. depending on how many versions you think you might release.

If you're releasing a very early version of your product - one that's not feature complete - then your might want to go with version "0". That way you can increment the version over time as you fill out your feature set.

I'd use "Alpha" and "Beta" like Release Candidate - for time limited versions to indicate that you think you are close to releasing the full version.

ChrisF
  • 38,878
  • 11
  • 125
  • 168
  • I thought about this, but I can't quite wrap my head around what version 0 represents. The difference between 0.1 and 0.2, and between 0.3.2 and 0.3.3, simultaneously do and don't make sense to me according to the "minor release"/"bugfix patch" model. – Pops Mar 13 '11 at 18:09
  • @Lord - admittedly that's where it does fall down... – ChrisF Mar 13 '11 at 18:17
1

There's a Wikipedia page on Software Versioning. For sharing pre-1.0 versions, the convention used by Apple and others works well: major.minor.maintSrev where S is the stage indicator for prerelease versions: d=development, a=alpha, b=beta, rc=release candidate. So your first internal version could be 1.0.0d1.

For completely internal revisions, the timestamp is sufficient.

xan
  • 111
  • 3
0

Each developer for the most part decides what standard they're going to use. In general though numbers to the left of the decimal point indicate large revisions that would likely be very noticeable to the average user (i.e. functionality or interface changes, etc). On the right side of the decimal point this would be a change/modification/addition that didn't change the overall functionality and design much but did change something about the program itself (ie make a function faster while still doing the same thing or fixed a security issue). Then if you add additional decimal points the numbers to the right of these would indicate increasingly smaller and smaller changes (i.e. minor bug fixes/security issues and such).

Kenneth
  • 2,703
  • 2
  • 21
  • 30
  • This would be a good answer for some of the related questions I listed in my post -- and, in fact, is pretty similar to some of the existing answers to those questions -- but doesn't really address the "version zero" case I'm asking about. – Pops Mar 13 '11 at 18:20
  • Why doesn't it? Everything starts out with 0 in computer science... – Kenneth Mar 13 '11 at 19:10
  • honestly in the end the only person/people the version number has significant meaning to is the developer(s). As for the users it only has relative meaning. So in the end developers can pretty much and more or less do use what ever scheme they feel like. – Kenneth Mar 13 '11 at 19:14
0

As others have said, there doesn't seem to be an exact standard. Our organisation uses the following notation:

Release 1.0 ---> 2.0 (A major new/improved feature added to the product)

Release 1.0 ---> 1.1 (A medium level new/improved feature added to the product)

Release 1.0 ---> 1.001 (Bugfixes)

Dalbir Singh
  • 857
  • 7
  • 10
  • 1
    "1.0 ---> 1.001 (Bugfixes)" Really? Why not 1.0.1? That's more usual. What happens if you have 100 bug fixes? – James Mar 14 '11 at 01:03
  • @James - That will NEVER happen (Famous last words I know lol). Seriously though, we've never reached a 100 bugfixes at one time, and so the sub release number has always changed before we reach this limit (1.1,1.2,1.3 etc). If we did reach the limit then we may have to increase the sub release number - it would count as a medium/level improved feature with that many fixes. – Dalbir Singh Mar 14 '11 at 08:56
0

The "version 1.0" milestone is very important to experienced computer users, as it implies that the program is done and works as expected. Anything in version "0.something" implies that the programmers themselves thinks that the program is not done yet.

You can keep the "0.1", "0.2" ... version numbers for major accomplishments of functionality and then subset it with a build number which frequently is a sufficiently fine grained date and timestamp.