[0.2] Document the MSRV of the stable channel as 1.63 #4040
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
r? @JohnTitor rustbot has assigned @JohnTitor. Use |
tgross35
changed the title
Noratrieb
reviewed
Nov 15, 2024
tgross35
force-pushed
the
stable-msrv
branch
from
297cea6 to
f43fcd3
Compare
Amanieu
approved these changes
Nov 15, 2024
cuviper
approved these changes
Nov 15, 2024
Currently this crate maintains the `main` branch (future 1.0) alongside `libc-0.2` (current stable release). PRs are made against `main` then cherry picked as applicable to `libc-0.2`. Usually this flow works okay, but there is a substantial difference in minimum supported versions: libc-0.2 is tested down to 1.19 and main is tested with 1.63. This means that supported features differ quite a bit and as a result, cherry picks get conflict-heavy (e.g. `repr(align)`, `union`, and `const fn` cannot be used on `libc-0.2`). In order to make it easier to keep these branches in sync and get us close to a 1.0 release, raise the MSRV on `libc-0.2` to 1.63. This means both branches can run the exact same tests. Future Changes ============== This still does not establish a MSRV policy, which has been discussed at great length in [1]. For the purpose of unsticking us this selects 1.63 as the MSRV, which is the version currently available on Debian stable (a commonly requested reference point in [1], and about the oldest specific version mentioned). This is a documentation-only change to keep things simple, cleanup can follow. Further increases and official policy are not precluded. History ======= An attempt to raise the MSRV to 1.57 in 2022 was approved at one point [2], but never merged due to various failures. Making this a documentation-only change hopes to avoid this problem. I brought up a 0.3 release to increase versions in [3], but consensus there was that we should be able to increase the MSRV in the existing 0.2 release without a semver-breaking change. Link: rust-lang/libs-team#72 [1] Link: rust-lang#2845 [2] Link: rust-lang/libs-team#463 [3]
tgross35
force-pushed
the
stable-msrv
branch
from
f43fcd3 to
93052d1
Compare
joshtriplett
approved these changes
Nov 15, 2024
tgross35
added a commit
to tgross35/rust-libc
that referenced
this pull request
Nov 16, 2024
With the change to MSRV in [1], update Cargo.toml `rust-version` to match. [1]: rust-lang#4040
tgross35
added a commit
to tgross35/rust-libc
that referenced
this pull request
Nov 16, 2024
Since the increase to MSRV in [1], we no longer need to test with old versions of Rust. [1]: rust-lang#4040
tgross35
added a commit
to tgross35/rust-libc
that referenced
this pull request
Nov 16, 2024
Since the increase to MSRV in [1], we no longer need to test with old versions of Rust. This makes CI identical to `main`, with the exception of branch configuration. [1]: rust-lang#4040
dtolnay
approved these changes
Nov 16, 2024
tgross35
added a commit
to tgross35/rust-libc
that referenced
this pull request
Nov 16, 2024
Since the increase to MSRV in [1], we no longer need to test with old versions of Rust. This makes CI identical to `main`, with the exception of branch configuration. [1]: rust-lang#4040
This was referenced Nov 16, 2024
newpavlov
added a commit
to rust-random/getrandom
that referenced
this pull request
Nov 21, 2024
This follows the MSRV bump in `libc`: rust-lang/libc#4040
24 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently this crate maintains the
mainbranch (future 1.0) alongsidelibc-0.2(current stable release). PRs are made againstmainthen cherry picked as applicable tolibc-0.2.Usually this flow works okay, but there is a substantial difference in minimum supported versions: libc-0.2 is tested down to 1.19 and main is tested with 1.63. This means that supported features differ quite a bit and as a result, cherry picks get conflict-heavy (e.g.
repr(align),union, andconst fncannot be used onlibc-0.2).In order to make it easier to keep these branches in sync and get us close to a 1.0 release, raise the MSRV on
libc-0.2to 1.63. This means both branches can run the exact same tests.Future Changes
This still does not establish a MSRV policy, which has been discussed at great length in [1]. For the purpose of unsticking us this selects 1.63 as the MSRV, which is the version currently available on Debian stable (a commonly requested reference point in [1], and about the oldest specific version mentioned).
This is a documentation-only change to keep things simple, cleanup can follow. Further increases and official policy are not precluded.
History
An attempt to raise the MSRV to 1.57 in 2022 was approved at one point [2], but never merged due to various failures. Making this a documentation-only change hopes to avoid this problem.
I brought up a 0.3 release to increase versions in [3], but consensus there was that we should be able to increase the MSRV in the existing 0.2 release without a semver-breaking change.
Link: rust-lang/libs-team#72 [1]
Link: #2845 [2]
Link: rust-lang/libs-team#463 [3]