-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
[stable] Add back Manifest::targets_mut #8527
[stable] Add back Manifest::targets_mut #8527
Conversation
It is needed by cargo-c, it was removed in df5cb70
Hm, highfive didn't assign for some reason, let's r? @ehuss |
Would y'all also be prepared to make a point release of Cargo, and if so that version bump should probably happen here too. This seems like a harmless backport but this isn't something that we've done before. |
Oh, yeah, including the version bump makes sense to me. I've pushed up a commit doing so, though please check (not sure if that's the only place I need to update). I was thinking we'd potentially just release it to crates.io without even inclusion in upstream Rust, since it won't affect that, but happy to do either -- we haven't yet built artifacts for rust stable point release so there's still time. |
Agreed. This doesn't need a point release of Rust binary artifacts, because anything using cargo-the-crate rather than cargo-the-binary should be using cargo from crates.io. |
To be clear we're doing a binary promotion anyway, so it doesn't matter whether this is in it or not to me. I would like to get a hard yes/no on that by end of this week though if possible, so we can get artifacts built and ready for shipping next Thursday. Let me know if I should do anything further or can help coordinate. (It also looks like CI here is failing, but I suspect that's spurious?) |
We talked about this in the Cargo meeting today and our conclusion was that it's fine to backport this. More generally, though, we're willing to review these sorts of API-level backports but none of us really wanted to manage the work to actually do the backport. @Mark-Simulacrum are you ok signing up to do all that? We were thinking it includes things like:
Would you be ok being responsible for this? So long as someone's signed up to do all the work we're ok backporting changes like this. |
I can do all that. I seem to recall hearing we should just merge this PR, rather than invoke bors? I'll post beta backports and such tomorrow. |
Yeah bors doesn't listen to azure and nightly is broken for unrelated reasons so manual merge is fine |
It is needed by cargo-c, it was removed in df5cb70.
This is a stable backport of #8494. It's technically fixing a stable/stable regression, so this seemed like a good idea. If this is accepted I can also prepare a backport to 1.46 (current beta).