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

go get -u doesn't follow the unstable v0 semantics #438

Closed
Julio-Guerra opened this issue Dec 7, 2022 · 3 comments
Closed

go get -u doesn't follow the unstable v0 semantics #438

Julio-Guerra opened this issue Dec 7, 2022 · 3 comments

Comments

@Julio-Guerra
Copy link

Hey,

I wanted to share the fact we are experiencing compilation issues when go-tuf releases a API breaking changes we rely on because go get -u alone upgrades go-tuf to the latest minor version available, regardless of the fact it is an unstable v0. See also this go issue for extra details.

Right now, I don't see any other solution but having copying go-tuf into our package to avoid this.

Have you already faced this problem before? If so, do you see any other solution? Or could you consider starting to use a stable versioning?

@asraa
Copy link
Contributor

asraa commented Dec 7, 2022

Hi, thanks for th e issue:
I don't see why you need to copy the entire package, because you can always specify the exact package version via go get -u github.com/theupdateframework/go-tuf@package-that-works or by modifying the go.mod you have.

That being said, the change is fairly simple -- just change InitLocal to Init

@Julio-Guerra
Copy link
Author

Julio-Guerra commented Dec 7, 2022

My point is that some go users rely on go get -u alone to upgrade all their dependencies to the latest minor versions, because a minor version isn't expected to break its API. But unfortunately, go-get doesn't consider v0 as an unstable version where a minor version can introduce breaking changes.
Such go get -u users are not expecting to see their transitive dependencies not compiling anymore.

@znewman01
Copy link
Contributor

We're not really ready to commit to a 1.0 release yet; at some point we will but I don't want to rush it to work around a Go tooling bug. Unfortunately nothing to do here AFAICT other than wait and invest more effort in go-tuf itself.

If you have other suggestions I'm all ears.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants