semver
semver copied to clipboard
maxhauser
Incrementing
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.)
I had no actual plans to include versioning incrementing, but if you contribute the functionality, I certainly welcome it.
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.
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?
What are people's thoughts on an
Increment(Part)method wherePartis an enum ofMajor,Minor,Patchvs three methodsIncrementPatch(),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.
