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

x/exp/cmd/gorelease: don't accept invalid -version increments #37558

Closed
jayconrod opened this issue Feb 28, 2020 · 3 comments
Closed

x/exp/cmd/gorelease: don't accept invalid -version increments #37558

jayconrod opened this issue Feb 28, 2020 · 3 comments
Labels
FeatureRequest FrozenDueToAge modules NeedsFix The path to resolution is known, but the work has not been done. Tools This label describes issues relating to any tools in the x/tools repository.
Milestone

Comments

@jayconrod
Copy link
Contributor

gorelease should report an error when the -version flag is set to a version much higher than any current version. New versions should be consistent with Semantic Versioning.

For example, if the only known version of a module (as reported by go list -m -versions) is v1.2.3, then -version may be set to v1.2.4 or v1.3.0. v1.2.5 and v1.4.0 would be rejected. v1.3.1 would also be rejected, since the patch version is not set to zero.

This check would not apply to pre-release versions (e.g., v1.5.0-pre) or to versions with major version v0.

@jayconrod jayconrod added NeedsFix The path to resolution is known, but the work has not been done. FeatureRequest arch-wasm WebAssembly issues modules arch-riscv Issues solely affecting the riscv64 architecture. arch-ppc64x Tools This label describes issues relating to any tools in the x/tools repository. arch-arm64 labels Feb 28, 2020
@jayconrod jayconrod added this to the Unreleased milestone Feb 28, 2020
@jayconrod jayconrod removed arch-wasm WebAssembly issues arch-arm64 arch-ppc64x arch-riscv Issues solely affecting the riscv64 architecture. labels Feb 28, 2020
@qmuntal
Copy link
Contributor

qmuntal commented Jul 16, 2020

New versions should be consistent with Semantic Versioning.

I can't find in the semantic versioning spec where it specifies that all version increments shall be 1 unit steps, to my understanding it only requires incremental versions, thus skipping versions is allow.

This policy could be too much strict for the CI/CD pipelines that automatically increment the patch using an auto-incremented counter that are hard to reset in case of build failure, p.e. when using a counter in azure devops.

@jayconrod
Copy link
Contributor Author

It looks like the requirement to increment version numbers by 1 was dropped between semver 1.0.0 and 2.0.0. There's some discussion on their issue tracker. So enforcing increment-by-1 is too strict. I'll close this issue.

This policy could be too much strict for the CI/CD pipelines that automatically increment the patch using an auto-incremented counter that are hard to reset in case of build failure, p.e. when using a counter in azure devops.

Using a build counter as a patch version number should work, but I think it's going to be inconvenient in a lot of cases. If there's a compatible change to the API or to visible functionality, you should increment the minor version number and set the patch version number to zero; a counter can't do that. If there are builds on different branches sharing the same counter, it won't grow together with version numbers either.

@qmuntal
Copy link
Contributor

qmuntal commented Jul 16, 2020

Just for completeness, the comment gorelease.go#L109-L112 should be deleted so no one tries to implement this idea without knowing about this discussion.

If there's a compatible change to the API or to visible functionality, you should increment the minor version number and set the patch version number to zero; a counter can't do that. If there are builds on different branches sharing the same counter, it won't grow together with version numbers either.

@jayconrod thanks for the advice, I do take care of this cases.

@golang golang locked and limited conversation to collaborators Jul 16, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FeatureRequest FrozenDueToAge modules NeedsFix The path to resolution is known, but the work has not been done. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
None yet
Development

No branches or pull requests

3 participants