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/build: update x/ dependencies in untagged x/ repos when applying tags #56530

Open
bcmills opened this issue Nov 2, 2022 · 4 comments
Open
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@bcmills
Copy link
Member

bcmills commented Nov 2, 2022

Now that we are automatically tagging releases for many of the golang.org/x/... repos (#48523), we are incidentally updating the other x-repo dependencies in their go.mod files. However, some of our x repos that are not currently tagged (notably x/debug) also depend on the tagged x repos, and those currently require manual updates (as in https://go.dev/cl/446515).

When we add a new tag for an x repo, it would be nice to also update the untagged x repos that depend on it to prevent our internal dependencies from getting too stale.

(As @dmitshur pointed out to me, x dependencies are safe to upgrade because they have necessarily gone through Go's code review process, whereas upgrading non-x dependencies may require auditing upstream changes.)

@gopherbot gopherbot added the Builders x/build issues (builders, bots, dashboards) label Nov 2, 2022
@gopherbot gopherbot added this to the Unreleased milestone Nov 2, 2022
@bcmills bcmills added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. and removed Builders x/build issues (builders, bots, dashboards) labels Nov 2, 2022
@FiloSottile
Copy link
Contributor

FiloSottile commented Nov 17, 2022

I found this issue because I wanted to ask why are we blindly updating x/ module inter-dependencies. I'm not sure consumers (us included) should be forced to update every (or, rather, an arbitrary subset) x/ repo every time they update one, if there is no actually related change.

For example, v0.3.0 of x/crypto depends on v0.2.0 of x/net because of the automatic upgrades, but the standard library is on v0.1.0. CL 353849 needs to bring in a recent x/crypto change. Without that upgrade, I could have just pulled x/crypto up in CL 353849. Instead, I now have to make a separate CL that also imports unrelated http2 changes in x/net.

@dmitshur
Copy link
Contributor

dmitshur commented Nov 17, 2022

@FiloSottile This question is a better fit for issue #36905, if I understand it correctly. With the 1.20 freeze coming up next week, we will be updating the std and cmd modules to vendor the latest tip versions of all golang.org/x modules, which will include x/net's v0.2.0 and 4 commits since.

@FiloSottile
Copy link
Contributor

FiloSottile commented Nov 17, 2022

@dmitshur I don't think it's related to #36905: first, the stdlib case is just an example of why a consumer might not want to pull in unrelated updates when updating a x/ repo. Non-stdlib modules might also want to selectively update. Second, if the std bump comes at the start of the freeze, it won't help me with CL 353849 unless we make a freeze exception, because CL 353849 depends on the x/crypto bump.

This issue is about automatically updating x/ dependencies in untagged x/ repos. What I'm saying is that I don't understand why we are automatically updating x/ dependencies in any x/ repos at all.

@bcmills
Copy link
Member Author

bcmills commented Nov 17, 2022

In general it isn't feasible to test every x repo commit against every commit to each of its dependencies, so there will always be some amount of “untested skew” between the repos: that is, an accidental breaking change (or accidental dependency on an implementation detail) may break a package or test in another repo without causing the build for that repo to immediately fail.

Keeping the dependencies without our repos reasonably up-to-date limits that skew to a smaller interval of time and a smaller of interval of changes, making it more likely that the incompatibility will be noticed (and fixed) quickly and also reducing the number of commits that may need to be bisected in order to diagnose a regression.

(Note that we can update the x repos automatically because they all have the same code-review requirements. We cannot apply the same policy to automatically update third-party dependencies, because we may need to audit the changes in those dependencies before we can safely use them.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
Status: Planned
Development

No branches or pull requests

4 participants