Repository navigation
New-ModuleManifest should set ModuleVersion to 0.1 by default #4823
Description
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.psd1Expected behavior
...
ModuleVersion = '0.1'
...
Actual behavior
...
ModuleVersion = '1.0'
...
Environment data
> $PSVersionTable
Reacted by Joel Bennett
Reacted by Joel Bennett
Activity
Jaykul commentedon Sep 13, 2017
Nope, that's wrong!
See the spec:
SteveL-MSFT commentedon Sep 13, 2017
Leading zero means it can't be 001.002.003, but the major version can be 0. 0.1.0 is probably more correct.
mklement0 commentedon Sep 13, 2017
Aside from fixing the syntax issue (
0.1->0.1.0- though casting to[semver]curiously works with0.1too, and even with just0), can I suggest even more humble beginnings, namely0.0.1?At least in the world of Node.js / npm, the
0.0.xrange is nowadays used for early development - see here for background info.iSazonov commentedon Sep 13, 2017
0.1.0looks good to me. We actually use it now, so we just need to add zero.SteveL-MSFT commentedon Sep 13, 2017
SemVer recommends
0.1.0although it doesn't say0.0.1isn't allowed. Personally, I prefer0.1.0as the default and someone could always explicitly use0.0.1if they choose.mklement0 commentedon Sep 13, 2017
Steve Lee (@SteveL-MSFT):
0.1.0is definitely an improvement over1.0and, as you state,0.1.0is 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):So what the Node.js / npm community has done is to extend the rules to cover <
1.0.0in an effort to support a two-stage approach to releasing:Allow beta releases of sorts in the <
1.0.0range, with beta testers / early adopters being able to rely on rules analogous to the >1.0.0ones 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, withm>= 1: changes tomare breaking changes, changes top(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 commentedon Sep 13, 2017
Michael Klement (@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.1and if a user wants to use0.1.0, they can certainly specify that.LDSpits commentedon Sep 14, 2017
I'm willing to pick up this issue. Can I get it assigned? Looks relatively easy to implement.
SteveL-MSFT commentedon Sep 14, 2017
Lucas Spits (@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-grabsthat we think are easy and not high priority.