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

cmd/go: add better support for v0.YYYYMMDD.HHMMSS versions #35646

Closed
magiconair opened this issue Nov 17, 2019 · 2 comments
Closed

cmd/go: add better support for v0.YYYYMMDD.HHMMSS versions #35646

magiconair opened this issue Nov 17, 2019 · 2 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Milestone

Comments

@magiconair
Copy link
Contributor

What version of Go are you using (go version)?

go version go1.13.4 darwin/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

darwin/amd64

What did you do?

We recently switched to module versions of the form v0.YYYYMMDD.HHMMSS since we only care whether a module is more recent and we already had existing semver tags in the repo. So v0.0.YYYYMMDDHHMMSS would not work.

This works fine until the timestamp starts with a 0 since then the patch version is outside the semver spec. go build then fails but go mod tidy fetches the version but rewrites go.mod to v0.20191115.124623-0.20191117071016-50581b53fb34. This does not happen after 10:00 obviously.

We can switch to something like v0.99.YYYYMMDD.HHMMSS or v1.0.YYYYMMDDHHMMSS but I'm wondering whether it would make sense to make the semver parser a bit more lenient to allow for this use-case.

@jayconrod
Copy link
Contributor

I'd be concerned about deviating further from the semver spec. This would create ambiguity when comparing versions (does v1.2.03 come before or after v1.2.3?) and give room for bugs to hide.

Could you use a pre-release suffix for this instead? For example, v0.0.1-YYYYMMDDHHMMSS.

@toothrot toothrot added this to the Backlog milestone Nov 18, 2019
@toothrot toothrot added WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Nov 18, 2019
@magiconair
Copy link
Contributor Author

Ah, that's a good point and that would indeed create confusion. We're using v1.0.YYYYMMDDHHMMSS now since these are more recent than the other tags we've created so far and also does not have that problem.

Closing and thank you.

@golang golang locked and limited conversation to collaborators Nov 19, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Projects
None yet
Development

No branches or pull requests

4 participants