It really depends. Typically a 0.x would be a beta release. 1.9.9 could be a stable release, or it could be a beta for version 2.0. Some projects use even numbered minor release numbers to denote stable releases, and odd numbers to denote unstable releases (for example, linux, 2.4.x and 2.6.x are stable, or gnome, where the stable release is 2.16 and the previous stable release was 2.14)
Ideally, the closer 0.x gets to 1.0, the more stable the API should be. Once it's 1.0, the API shouldn't change until the major changes again. But, how closely this rule is followed varies as well. Lua 5.1 has some minor API changes from 5.0. The Linux kernel makes drastic API changes between minor versions.
For Aleph One, it's pretty simple. We have a couple releases a year, and the minor version number gets incremented for each. There are a few preview builds for each one, which has the upcoming release's minor version number and a pre1 or pre2 tacked on. Then some release candidates, which have rc1 or rc2. Then if there are some small changes necessary for scenario compatibility or outrageous bugs, there can be point releases (0.16.1, 0.16.2), and if there's a tiny change necessary for one of the builds, we just use the same version number and put a -r1 after the tarball on sourceforge.
We're at the point now where we're stable enough to be called 1.0, but I would like to see the interface cleaned up a bit more, and more importantly, Marathon 2 film compatibility restored, before we take that step (which will get us a lot of PR)
As for what number projects start at, I think developers just try to guess how close they are to 1.0 and leave themselves enough room for the appropriate number of releases. Aorta started at 0.5 and then went to 0.9 and quickly 1.0.
