How do early version numbers work for new products

naming

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.

Best Answer

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