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

[stable] Add back Manifest::targets_mut #8527

Merged
merged 2 commits into from
Jul 22, 2020

Conversation

Mark-Simulacrum
Copy link
Member

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).

It is needed by cargo-c, it was removed in df5cb70
@Mark-Simulacrum
Copy link
Member Author

Hm, highfive didn't assign for some reason, let's r? @ehuss

@alexcrichton
Copy link
Member

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.

@Mark-Simulacrum
Copy link
Member Author

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.

@joshtriplett
Copy link
Member

I was thinking we'd potentially just release it to crates.io without even inclusion in upstream Rust, since it won't affect that

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.

@Mark-Simulacrum
Copy link
Member Author

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?)

@alexcrichton
Copy link
Member

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:

  • The stable backport (this PR)
  • The version bump (this PR)
  • The publish once merged
  • The beta backport
  • The stable submodule update
  • The beta submodule update

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.

@Mark-Simulacrum
Copy link
Member Author

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.

@alexcrichton
Copy link
Member

Yeah bors doesn't listen to azure and nightly is broken for unrelated reasons so manual merge is fine

@alexcrichton alexcrichton merged commit f242df6 into rust-lang:rust-1.45.0 Jul 22, 2020
@Mark-Simulacrum Mark-Simulacrum deleted the rust-1.45.0 branch July 23, 2020 14:07
@ehuss ehuss added this to the 1.45.0 milestone Feb 6, 2022
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

Successfully merging this pull request may close these issues.

5 participants