What to use as an initial version? [closed]

Question

The Semantic Versioning 2.0.0 standard provides the 0.y.z space to indicate that your project does not have a stable public API:

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

It is suggested to start at 0.1.0 and bump the minor version on every breaking change to the public API. You can increment to 1.0.0 when you are in a position to appropriately control and manage these breaking changes:

Version 1.0.0 defines the public API. The way in which the version number is incremented after this release is dependent on this public API and how it changes.

The benefit of using the 0.y.z space is that you will not reach a high major version, e.g. 142.6.0, during initial development. It tends to be industry convention to avoid high major version numbers, partially for marketing reasons, but this may not be relevant to you.

Semantic Versioning applies specifically to projects with public APIs, but is often applied in other contexts with an alternative notion of "breaking change", e.g. large changes to GUI interfaces.

The version number is entirely up to you. Do what makes sense to you and be consistent. Nobody says you have to start from 0, or 0.0, or 1.0, or 1.1.

Great programmers have actually used the version numbering system as local jokes. Examples (Wikipedia):

Since version 3, TeX has used an idiosyncratic version numbering system, where updates have been indicated by adding an extra digit at the end of the decimal, so that the version number asymptotically approaches π. This is a reflection of the fact that TeX is now very stable, and only minor updates are anticipated. The current version of TeX is 3.1415926; it was last updated in March 2008

For METAFONT:

Metafont has a versioning system similar to that of TeX, where the number asymptotically approaches e with each revision.

Finally, not quite a version number, but equally interesting, is that Google's initial public offering (IPO) was filed with the SEC for raising $2,718,281,828 (notice that e~2.718 281 828).

My point is: don't feel that you need to follow the crowd. Be creative and consistent.

I think different factors come into play here. Psychological/marketing impact of the version number (version number increased often => more $$$, people don't want to buy a 0.99 beta version, etc) must be taken into account. "Logic" version numbers can help when working in a huge team.

And I like the linux way of having odd numbers for the unstable versions, and even numbers for the stable one.

When choosing version numbers for an npm package, be aware that for dependencies listed in package.json semver ranges won't work below v1.0.0. That is,

"dependencies": {
    "my-package": "^0.5"
}

is equivalent to

"dependencies": {
    "my-package": "0.5"
}

If you want to be able to use semver ranges, or you want to let other people use them, you might want to start with 1.0.0