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

Comments

@magiconair
Copy link
Contributor

@magiconair magiconair commented Nov 17, 2019

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

This comment has been minimized.

Copy link
Contributor

@jayconrod jayconrod commented Nov 18, 2019

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.

@magiconair

This comment has been minimized.

Copy link
Contributor Author

@magiconair magiconair commented Nov 20, 2019

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.

@magiconair magiconair closed this Nov 20, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.