What to use as an initial version?

Question

I usually start my projects with a version 1.0.0. As soon as I have some stuff together, I release it as 1.0.0 and move on with 1.1.0.

However, this leads to usable but not exactly feature complete version 1.0.0 of most stuff I write. I then add features and get to a decent version somewhere around 1.6.0. Many projects start with version 0.1.0, which will be as usable as my 1.0.0.

What would you suggest doing? Start with 1.0.0 or 0.1.0?

The last number is for bugfix releases only by the way. You can think of my 1.0.0 as 1.0 and 0.1.0 as 0.1 is that's easier for you.

Answer 1

When I get my first usable ready but not feature complete version, I normally try to judge how far along it is towards a feature complete version, so for example if my first usable is 33% feature complete I make the version number 0.3.0 or similar. Then as I move towards feature complete corresponding versions get given numbers in a similar way.

But once you move on past feature complete versioning needs to change

Answer 2

Start with 1.1.1 and move on from there.

Answer 3

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

Answer 4

Typically, the versioning has some meaning to the programmer. Increasing the major number might indicate large changes that prevent backwards-compatibility. Other numbers in the version number might indicate smaller feature enchancements or bug fixes.

If you are worried version 0.6.5 has an incomplete ring to it, you might want to market it under version 1.0. Your marketing version number need not match your internal version number. The version number of Windows 7, for instance, is 6.1.

My personal preference is to start from 0.1.0 and go from there.

Answer 5

The Semantic Versioning 2.0.0 standard says:

The simplest thing to do is start your initial development release at 0.1.0 and then increment the minor version for each subsequent release.

It is fine to go from 0.3.0 straight to 1.0.0. It is also perfectly okay to be at 0.23.0. Starting at 0.4.0 is somewhat unadvisable as it suggests there have been previous published versions.

Additionally, note that 0.y.z is kept aside for quick iteration, so that initial development (and hence lots of breaking changes) does not leave you at something silly like 142.6.0. Instead of bumping the major version, bump the minor version on every breaking change until you release 1.0.0:

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

Answer 6

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.