Powershell: New-ModuleManifest should set ModuleVersion to 0.1 by default

[joeyaiello]

Given our push for semantic versioning, I think it'd be helpful for the New-ModuleManifest defaults to set ModuleVersion to 0.1

I don't think this is a breaking change because -ModuleVersion provides deterministic behavior.

Steps to reproduce

New-ModuleManifest -Path ./foo.psd1

Expected behavior

...
ModuleVersion = '0.1'
...

Actual behavior

...
ModuleVersion = '1.0'
...

Environment data

> $PSVersionTable

[Jaykul]

Nope, that's wrong!

See the spec:

1. A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading zeroes... spec

[SteveL-MSFT]

Leading zero means it can't be 001.002.003, but the major version can be 0. 0.1.0 is probably more correct.

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

[mklement0]

Aside from fixing the syntax issue (0.1 -> 0.1.0 - though casting to [semver] curiously works with 0.1 too, and even with just 0), can I suggest even more humble beginnings, namely 0.0.1?

At least in the world of Node.js / npm, the 0.0.x range is nowadays used for early development - see here for background info.

[iSazonov]

0.1.0 looks good to me. We actually use it now, so we just need to add zero.

[SteveL-MSFT]

SemVer recommends 0.1.0 although it doesn't say 0.0.1 isn't allowed. Personally, I prefer 0.1.0 as the default and someone could always explicitly use 0.0.1 if they choose.

[mklement0]

@SteveL-MSFT:

0.1.0 is definitely an improvement over 1.0 and, as you state, 0.1.0 is what SemVer recommends, so the following is just food for thought:

SemVer also imposes virtually _no_ rules on any version < 1.0.0 (to recap what you've already quoted):

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

So what the Node.js / npm community has done is to extend the rules to cover < 1.0.0 in an effort to support a two-stage approach to releasing:

• Allow beta releases of sorts in the < 1.0.0 range, with beta testers / early adopters being able to rely on rules analogous to the > 1.0.0 ones to communicate changes, which means:

  • 0.0.p - no guarantees whatsoever - any change in the patch number can be a breaking one.
  • 0.m.p, with m >= 1: changes to m are breaking changes, changes to p (only) maintain backward compatibility and are either simple fixes or add functionality.

• Once you hit 1.0.0, after beta testing, when the API has settled, the official SemVer rules apply.

[SteveL-MSFT]

@mklement0 I can see value in standardizing and differentiating between 0.y.z and 0.0.z. I would be fine starting with 0.0.1 and if a user wants to use 0.1.0, they can certainly specify that.

[LDSpits]

I'm willing to pick up this issue. Can I get it assigned? Looks relatively easy to implement.

[SteveL-MSFT]

@LDSpits consider it assigned to you as GitHub doesn't let me assign to people to you. I'll set it assigned to me so someone else doesn't duplicate your effort. Thanks! We generally label issues Up-for-grabs that we think are easy and not high priority.