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/vgo: some way to opt out of semver for a while? #25734

Closed
josharian opened this issue Jun 5, 2018 · 7 comments

Comments

@josharian
Copy link
Contributor

commented Jun 5, 2018

This is more a question than anything.

After following (most of) the vgo discussion, I came away with a sense that gophers are expected to adhere strictly to semver, and in particular avoid breaking changes once v1 has been released.

But @rsc recently wrote in #25503 (comment):

[...] my suggestion is still a v2 top-level directory, and maybe a strongly worded v2/README.md that you are going to make backwards-incompatible changes there for a while.

There is a need for experimental phases after v1 has been released, as new major versions get worked on. It seems to me it would be better for the package authors to be able to communicate that directly to vgo somehow, instead of via a strongly worded README. (Somewhat related: #25524, although that might not be the preferred mechanism.)

@josharian josharian added this to the vgo milestone Jun 5, 2018

@kardianos

This comment has been minimized.

Copy link
Contributor

commented Jun 5, 2018

Question: if the goal is to communicate to vgo, what should vgo (the build system and MVS) do with this information?

If communicating with a user I would say v2.0.0-unstable-1

@josharian

This comment has been minimized.

Copy link
Contributor Author

commented Jun 6, 2018

Question: if the goal is to communicate to vgo, what should vgo (the build system and MVS) do with this information?

I'd say treat it as vgo does pre-1.0 versions. In particular don't assume semver compatibility promises. (But maybe I'm just confused about all of this. Wouldn't be the first time.)

@kardianos

This comment has been minimized.

Copy link
Contributor

commented Jun 6, 2018

vgo, the build tool and mvs, doesn't care about compatibility. It does care about semantic import paths which allows v5 to be a different package then v4.

I don't think that matters to the vgo build tool. It would matter to a hypothetical "go release" compatibility checker tool though.

@myitcv

This comment has been minimized.

Copy link
Member

commented Jun 6, 2018

Could you not make the breaking changes on a branch (could be master), where the go.mod on the branch has the /v2 (or whatever major version you're at) added. Then use vgo get example.com/hello/v2@branch_name to use v2 (in this case) pseudo-version?

@hyangah

This comment has been minimized.

Copy link
Contributor

commented Jun 6, 2018

One of the confusion I had (and still have) while reading vgo blog posts is the relationship between the samantic version import and the semver looking version tag used in go.mod.

According to @myitcv's comment, I assume we can even continue using golang.org/x/debug/v2 with v0.0.0-(utctime)-(commitid) convention. Similarly golang.org/x/debug can be tagged with v999.0.0, which matches one of the examples in the 6th blog post. Am I misunderstanding it?

@malexdev

This comment has been minimized.

Copy link

commented Jun 6, 2018

I'm not sure how vgo plans to handle this, but per semver, versions such as 2.0.0-alpha or 2.0.0-alpha.2 are supported in the spec.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Jun 6, 2018

@josharian That comment was in the context of the x repos, where we are still working out what the general plan is for tagging versions (more complex than most because they are kind of monorepo-esque). If actually tagging things was an option (we're just not ready yet) then we'd put a v2/go.mod there that said module golang.org/x/debug/v2 and either not issue any tags at all (in which case it would be all pseudo-versions, and you get what you get) or use tags like v2.0.0-unstable-SOMETHING. That kind of prerelease semver tag is how you opt out of compatibility, which is what I think you meant instead of "opt out of semver". The strongly worded README is only necessary because we haven't finalized plans for golang.org/x.

@hyangah If the module path ends in /v2, then the version in go.mod must begin with v2. For a v2 module you'd use a pseudo-version that was v2.0.0-time-commit instead of v0.0.0-time-commit.

golang.org/x/debug can be tagged with v999.0.0 but unless there is a go.mod there saying module golang.org/x/debug/v999 and the code is imported that way, that tag is not going to be used by vgo.

@rsc rsc closed this Jun 6, 2018

@golang golang locked and limited conversation to collaborators Jun 6, 2019

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
7 participants
You can’t perform that action at this time.