Skip to content
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.

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

Incrementing #10

Open
ben-biddington opened this issue May 29, 2015 · 4 comments
Open

Incrementing #10

ben-biddington opened this issue May 29, 2015 · 4 comments
Labels
comments-wanted Input is desired on how or whether this items should be done enhancement
Milestone

Comments

@ben-biddington
Copy link

Glad to find this library does most things -- are there plans to align versioning incrementing with semver 2.0.0?:

... Patch and minor version MUST be reset to 0 when major version is incremented.

semver incrementing major does not zero minor and patch.

(I will add it of you're interested.)

@maxhauser
Copy link
Collaborator

I had no actual plans to include versioning incrementing, but if you contribute the functionality, I certainly welcome it.

@WalkerCodeRanger
Copy link
Owner

What are people's thoughts on an Increment(Part) method where Part is an enum of Major, Minor, Patch vs three methods IncrementPatch(), IncrementMinor(), IncrementMajor()?

Also, what should happen to the prerelease and build metadata when incrementing. I'm kind of thinking they should be cleared, but I can imagine situations where you wouldn't want that.

@WalkerCodeRanger WalkerCodeRanger added the comments-wanted Input is desired on how or whether this items should be done label Oct 25, 2019
@WalkerCodeRanger WalkerCodeRanger pinned this issue Dec 31, 2020
@WalkerCodeRanger
Copy link
Owner

WalkerCodeRanger commented Jun 19, 2021

An alternative API would be a Next(Part) method or NextMajorVersion, NextMinorVersion, and NextPatchVersion.

Another question is how these should handle starting from prerelease. For example SemVersion.Parse("1.1.0-rc").NextMinorVersion(), should that return 1.1.0 or 1.2.0?

@cn-ml
Copy link

cn-ml commented Aug 1, 2023

What are people's thoughts on an Increment(Part) method where Part is an enum of Major, Minor, Patch vs three methods IncrementPatch(), IncrementMinor(), IncrementMajor()?

I prefer the fixed methods <name>Patch(), <name>Minor(), <name>Major() to not introduce any new types. However for the name I'd say the Next<type>Version() methods are more clear on intent to create a new successor version instead of incrementing the current one.

Also, what should happen to the prerelease and build metadata when incrementing. I'm kind of thinking they should be cleared, but I can imagine situations where you wouldn't want that.

I dont think metadata or prereleases should be kept. A new version definitely signals a new build context (new (or the same) metadata can be added in a second call if needed). Prereleases should also be cleared in my opinion, as they refer to the patch version instead of the minor in case of a bump.

@WalkerCodeRanger WalkerCodeRanger added this to the v3.1.0 milestone Sep 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
comments-wanted Input is desired on how or whether this items should be done enhancement
Projects
None yet
Development

No branches or pull requests

4 participants