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
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
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
- A is the major version. This will rarely change and signify very large
- 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.
- 1.0.0 : first GA release
- 1.0.x : bug fixes to 1.0.x - highly recommended to upgrade, very
- 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