search

nix-rust / nix

Rust friendly bindings to *nix APIs
MIT License
2.69k stars 670 forks source link

Backport fixes to earlier releases? #1881

Closed rtzoeller closed 1 year ago

rtzoeller commented 2 years ago

The upcoming 0.26 release will fix several bugs -- as previous releases included or will include breaking changes, it may not be possible for all clients to trivially uptake these bug fixes by upgrading to the latest version of nix. Additionally, 0.26 will bump the MSRV, making it difficult for clients stuck on an older rust to adopt these fixes.

@asomers should we backport any of the fixes to patch earlier releases?

Here's a draft list of changes to backport to each version:

0.25

0.24

0.23

0.22

rtzoeller commented 2 years ago

Some but not all of these bugs would also apply to 0.23, which I believe is also still fairly heavily used per the download statistics on https://crates.io/crates/nix. We could also backport and release a new patch for this branch, if desired.

asomers commented 2 years ago

You're right. And even 0.22 has 10k downloads per day. We should probably backport.

rtzoeller commented 2 years ago

I'm happy to handle the actual cherry-picking and release processes; I think it can all wait until we have 0.26 released though.

If we're applying fixes across 0.22 <-> 0.25, it'd be helpful to have a list of changes we want to cherry-pick into each version. There might be some fixes from 0.23 <-> 0.25 that we want to cherry-pick back to 0.22, for example.

I've updated the original issue to provide a space for this list.

rtzoeller commented 2 years ago

@asomers should we backport #1642 to 0.23 and 0.22? We deprecated InetAddr::from_std in 0.24, which was ironically the first release containing #1642.

Not sure how we feel about applying fixes to since-deprecated APIs, but it seems easy enough to include if we're already fixing things.

asomers commented 2 years ago

If it's easy, sure. But I don't want to expend too much energy maintaining old releases.

wesleywiser commented 2 years ago

I'm working on upgrading the version of musl used by the Rust *-linux-musl targets to musl 1.2. We unfortunately will have to make some breaking changes to the libc crate as part of that effort. I've done a crater run of the proposed changes which revealed a number of crates that no longer build because of compilation errors in various versions of the nix crate as a result of those libc changes:

Version Number of downstream crates broken
nix-0.22.3 32
nix-0.23.1 52
nix-0.24.2 111
nix-0.25.0 87

If you're going to be releasing updates to any of those versions, it would be awesome if you could include #1886! I would be happy to help with that and provide patches and testing for whatever versions you choose.

asomers commented 2 years ago

@rtzoeller I think I'll have some free time tonight or tomorrow evening to work on releases. I'll start with 0.26.0 and work my way backwards.

rtzoeller commented 2 years ago

@asomers if you can get 0.26.0 published (not sure if there are any other PRs we want to pull in), I'm happy to handle the backporting if you'd prefer. Not sure how much manual fixing of cherry-picks will be required.

rtzoeller commented 2 years ago

@wesleywiser if I'm understanding correctly, #1886 lets us support both musl 1.1 now and 1.2 in the future? In that case, I agree we should cherry-pick it back to those releases if possible. I'll add it to the list, but please thumbs up/down this comment to ack my understanding.

rtzoeller commented 2 years ago

@asomers I tried cherry-picking the commits and have added my notes to the issue body; very few conflicts and almost all could be solved by picking an additional commit.

1886 is the only painful one, just because we've added so much to src/sys/time.rs recently.

I expect there will be a healthy amount of clippy cleanup needed after cherry picking, unless we want to suppress things.

rtzoeller commented 2 years ago

@asomers I have drafts up for patches of 0.25, 0.24, and 0.23. I will get to 0.22 after we get a resolution on how to backport #1886. I see no reason to hold up 0.26.0 for that though.

rtzoeller commented 2 years ago

@rtzoeller need to backport https://github.com/nix-rust/nix/pull/1821 as well.

rtzoeller commented 2 years ago

@asomers can you look over #1887 and #1889? These should reflect the 0.25 and 0.24 patches - I plan on publishing these as soon as I get your go-ahead (i.e. not waiting for the 0.23 and 0.22 patches to be ready first).

I'm planning on closing the draft PRs and pushing directly to the branches, as it appears we have done in the past.

0.23 (#1892) is having some issues with the Redox build. We will also need to decide how to handle the mqueue changes from https://github.com/nix-rust/nix/pull/1639/files, as clippy is unhappy but the original fix was a breaking change not suitable for a patch release.

0.22 (#1901).... I am not sure what to do with. #1821 is nontrivial to backport due to #1524, which first landed in 0.23.0. We also were not running clippy at this point, and the build is failing for what appear to be infrastructure issues.

asomers commented 2 years ago

1887 and #1889 look good to me. I may be able to take a look at the other two this weekend, if I have time. Satisfying Clippy is always the hardest part about making patch releases.

rtzoeller commented 2 years ago

1892 should be ready for review; I'm not sure why the mqueue changes didn't come up, but I won't complain. Just needed to use a newer redox compiler and backport one redox fix.

rtzoeller commented 2 years ago

0.23, 0.24, and 0.25 are patched. 0.22 still remains, but I'm contemplating if our time is better spent updating crates which are still depending on that old of a version, rather than patching.

For example: https://github.com/watchexec/command-group/pull/8

asomers commented 1 year ago

Closing this issue. We never did publish another version of 0.22, and the world hasn't complained.