8000 New-ModuleManifest should set ModuleVersion to 0.1 by default · Issue #4823 · PowerShell/PowerShell · GitHub
[go: up one dir, main page]
Skip to content

New-ModuleManifest should set ModuleVersion to 0.1 by default #4823

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
joeyaiello opened this issue Sep 12, 2017 · 9 comments
Closed

New-ModuleManifest should set ModuleVersion to 0.1 by default #4823

joeyaiello opened this issue Sep 12, 2017 · 9 comments
Labels
Issue-Enhancement the issue is more of a feature request than a bug Resolution-Fixed The issue is fixed. WG-Cmdlets-Core cmdlets in the Microsoft.PowerShell.Core module

Comments

@joeyaiello
Copy link
Contributor

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
@SteveL-MSFT SteveL-MSFT added WG-Cmdlets-Core cmdlets in the Microsoft.PowerShell.Core module Issue-Enhancement the issue is more of a feature request than a bug Up-for-Grabs Up-for-grabs issues are not high priorities, and may be opportunities for external contributors labels Sep 12, 2017
@Jaykul
Copy link
Contributor
Jaykul commented Sep 13, 2017 •
edited
Loading

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
Copy link
Member

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
Copy link
Contributor

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
Copy link
Collaborator

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

@SteveL-MSFT
Copy link
Member

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
Copy link
Contributor
mklement0 commented Sep 13, 2017 •
edited
Loading

@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
Copy link
Member

@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
Copy link
Contributor
LDSpits commented Sep 14, 2017 •
edited
Loading

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

@SteveL-MSFT
Copy link
Member
SteveL-MSFT commented Sep 14, 2017 •
edited
Loading

@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.

This was referenced Sep 14, 2017
Closed
Merged
@SteveL-MSFT SteveL-MSFT added Resolution-Fixed The issue is fixed. and removed Up-for-Grabs Up-for-grabs issues are not high priorities, and may be opportunities for external contributors labels Sep 18, 2017
@SteveL-MSFT SteveL-MSFT removed their assignment Sep 18, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Issue-Enhancement the issue is more of a feature request than a bug Resolution-Fixed The issue is fixed. WG-Cmdlets-Core cmdlets in the Microsoft.PowerShell.Core module
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@Jaykul @mklement0 @joeyaiello @LDSpits @SteveL-MSFT @iSazonov
0