Is 0.0.1 valid semver?

Question

A colleague got into a casual argument about the first version of a module. We're wondering if 0.0.1 should be the initial release. I think 0.1.0 is the proper first version, as 0.0.1 implies an increment of a patch, and a patch implies a prior release. So from my understanding, there would have to be a 0.0.0.

I skimmed http://semver.org docs, which do say that 0.1.0 is usually the initial release, but I didn't see any rule against having a minor number set to 0 when the major version is also 0.

Does anyone know if 0.1.0 being the lowest possible version is a formal rule, or just a convention?

Answer 1

The semver 2.0.0 specification doesn't preclude it. The FAQ does recommend starting at 0.1.0 though.

How should I deal with revisions in the 0.y.z initial development phase?

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.

Answer 2

There are no rules here and conventions are loose.

When the initial major number is zero, all that is guaranteed is that higher numbers come after lower ones. All the semantic versioning guarantees about "this is a bug fix" or "old functionality still works" only apply to version one or later.

While there is a loose convention of 0.1.0 being the lowest version number, there are those that would argue it the first version one shares with others. The specification of semantic versioning simply sees the leading zero and washes its hands.

Answer 3

As per the semver calculator (https://semver.npmjs.com/), it is not recognizing the versions which start with 0.0.x.Semver Calculator Screenshot

Answer 4

Semantic versoning (semver) is about 'safely moving your project forward.' — from the last line of the second para of the docs Introduction.

By this definition and purpose we SHOULD bump our version number for each release (bump version then commit).

From docs (Rule #2): The version numbers (MAJOR, MINOR, and PATCH are non-negative integers).

If you started at 0.0.0 you must bump to something likely 0.0.1 or 0.1.0 where the MAJOR '0' indicates you are still in development.You could very well bump straight to 1.0.0 where the MAJOR '1' indiciates an initial public release.

Remember the rules, if you bump MAJOR you must reset MINOR & PATCH to '0' ... If you bump MINOR, you must reset PATCH to '0'. This prevents you from bumping all three simoustaneously.

In order to release 0.0.0 you must start at 0.-1.-1 or 0.0.-1 in your package.json (YOU CANNOT BY RULE #2) such that when you release (bump version then commit) you have a release with semver number 0.-1.0 (YOU CANNOT BY RULE #2) or 0.0.0;

The FAQ for semver 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." They are speaking about the actual release; after you have done the (bump version then commit). This is mentioned because you could have a release numbered 0.0.1 which indicates you FIXED SOME BUGS.

0.0.0 = Initial Development Release (Does Not Exist)

0.0.1 = Bugs Fixed Since (0.0.0 | Where You Began)

0.1.0 = Features Added Since (0.0.0 | Where You Began)