-
Notifications
You must be signed in to change notification settings - Fork 492
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
[BUG] Increase pre* with pre-release identifiers without build #441
Comments
Wouldn’t that mean you can only ever have one snapshot per version? That seems a bit short-sighted. |
This is correct, for MAVEN repositories the SNAPSHOT versions are allowed to be updated. (internal it uses a timestamp for the different versions) |
sounds like a build number. Why isn’t it part of the version number? |
The whole idea of the snapshot version is that you don't need to update references to it with every new build. See also What is a SNAPSHOT version?. |
Wouldn’t a semver range like |
Versions in semver are designed to be immutable - in other words, it’s not semver if it’s changing over time. |
1.2.3-SNAPSHOT is a perfectly valid semver. See this overview of the spec, where I marked the choices for the different options using
|
Absolutely that string is valid semver. But its contents must never change - versions are immutable. |
Fair enough, but whether I adhere to that rule should not be a problem when reasoning about the semver version. If we have semver version number |
Fair enough.
still worth establishing that it is not compliant, because snapshot contents change - and that by appending a |
The semver 2.0.0 spec mentions "increment" 16 times, but only for the major, minor, and patch versions. In it, I didn't see instructions on adding significant figures to any of the elements. |
What / Why
the semver package should be able to execute a increment premajor, preminor and prepatch for versioning schemes without a build number.
It for sure affects the standard maven versioning system (which is semver compliant).
Examples
Actual
0.0.1-SNAPSHOT premajor -> 1.0.0-SNAPSHOT.0
0.0.1-SNAPSHOT preminor -> 0.1.0-SNAPSHOT.0
0.0.1-SNAPSHOT prepatch -> 0.0.2-SNAPSHOT.0
Expected
0.0.1-SNAPSHOT premajor -> 1.0.0-SNAPSHOT
0.0.1-SNAPSHOT preminor -> 0.1.0-SNAPSHOT
0.0.1-SNAPSHOT prepatch -> 0.0.2-SNAPSHOT
Currently this package always sets a dot-separated build. I t would be desirable if the behavior could be chosen, or if it would at least respect the current versioning scheme.
The text was updated successfully, but these errors were encountered: