You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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
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.
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.
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 unstablev0
. 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?
The text was updated successfully, but these errors were encountered: