Rust, Python and Git Gave Notice of Default Changes in Different Ways: a Compiler Warning, an Opt-In Warning and a Build-Time Switch

Overview

Rust, Python and Git have each changed, or scheduled a change to, a default that existing code relies on. In the three cases below, the lead way each project warned developers differed: Rust emitted a compiler warning and then measured the breakage across public crates, Python chose an opt-in warning and its own proposal explains why, and Git documents planned breaks in advance, guards them behind a build-time switch and has laid out a run of transition releases. The three cases are the Herald’s own selection, made because each has been reported by an outlet independent of the project. The comparison is the Herald’s reading of what LWN, The Register, Phoronix and the projects’ own documents say, not a survey of every project’s practice.

Background

Each of the three has a stated mechanism for breaking changes. LWN describes Rust’s edition system as one that lets the project “allow breaking changes in the front-end design of the language without breaking older code or requiring the whole ecosystem to update at once.” Python’s PEP 686, the proposal behind the UTF-8 change, notes that “PEP 387 requires adding a warning for backward incompatible changes” but “doesn’t require using DeprecationWarning.” Git’s BreakingChanges document says the project releases breaking versions irregularly, names Git 1.6.0 (August 2008) and Git 2.0 (May 2014) as past examples, and says the cadence is “typically measured in multiple years.”

Current situation

Rust: a warning since 2024, then a scan of public crates

LWN reported on September 8 that the compiler contributor known as “waffle” stabilized Rust’s never type on August 24, “after more than two years of work.” Doing so involved a small breaking change to earlier editions. The Rust project’s 1.100 release post says the “never type fallback” changes from () to ! in the 2015, 2018 and 2021 editions, as it already had in edition 2024.

LWN says a crater run in April, which compiles publicly available crates, found “3,300 crates negatively impacted by the change” and that “only seven were fully broken”; LWN attributes the rest to dependence on old library versions that had since been fixed. According to LWN, Rust “has been emitting a warning whenever code triggers never-type fallback in a way that will break with the new change since 2024.” Backported fixes to library releases addressed 1,553 of the failing crates, though some maintainers refused, “on the grounds that those old versions were past their end of life.” LWN reports that the maintainers agreed to proceed even though “there would still be some broken code.” The three options it lists for affected users are to stay on Rust 1.99, update dependencies, or add explicit return types.

Rust 1.100 shipped on November 12, according to the Rust blog. The release post says the team tried to limit the impact “by providing future compatibility warnings far in advance and releasing fixes to public crates that have been broken by this.” Phoronix and Linuxiac covered the release and largely restate the project’s post; Linuxiac adds that the change “should affect few projects, but some existing code or dependencies may require updates.” The Herald reported the merge on September 11.

Python: an opt-in warning, chosen over a louder one

PEP 686 was created on March 18, 2022, targets Python 3.15 and has status Final. It says the change “mostly affects Windows users,” because most Unix systems use a UTF-8 locale and Python already enables UTF-8 mode when the locale is C or POSIX. For a program that depends on the default encoding, it says, the change “may cause UnicodeError, mojibake, or even silent data corruption,” so the change “should be announced loudly.” Yet the PEP rejected a deprecation warning for implicit encodings: “Emitting a lot of DeprecationWarning will lead users ignore warnings.” The notice it relies on is the EncodingWarning from PEP 597, which Python’s io documentation says was added in version 3.10 and is switched on with the -X warn_default_encoding option or the PYTHONWARNDEFAULTENCODING environment variable. The PEP adds that Ruby, which changed its Windows default in 3.0 (2020), and Java, in JDK 18 (2022), “don’t provide any warning like PEP 597’s EncodingWarning in Python for use of the default encoding.”

python.org lists a release date of October 9, 2026 for Python 3.15.0. The Register, in a piece published on October 14 at 13:00 UTC, said the release came “after a week’s delay” and described how earlier versions’ use of the host locale led to “much consternation for Windows developers.” The 3.15 release notes keep an opt-out, PYTHONUTF8=0 or -X utf8=0, and advise ensuring “an explicit encoding argument is always provided” for compatibility between versions. Linuxiac’s report on the release says the release “makes UTF-8 the default text encoding” and does not mention the opt-out or the warning. By the Herald’s arithmetic, about four and a half years separate the PEP’s creation from the release. The Herald’s earlier report on the stable release covers the wider feature list.

Git: a ledger, a build switch and a ladder of releases

Git’s BreakingChanges document, as read on November 13, lists changes held for Git 3.0, among them SHA-256 as the default hash for new repositories, reftable as the default reference storage for newly created repositories, main as the default branch name, and a mandatory Rust build. It requires that such changes sit behind a compile-time switch, WITH_BREAKING_CHANGES, so that a build can “behave as if these breaking changes slated for the next big version boundary are already in effect.” For the branch name, the document says the project has been warning about the change since a commit dated December 11, 2020. For Rust it sets three steps: auto-detection in the Meson build in Git 2.52, default-on in 2.55, mandatory in 3.0. Phoronix reported on June 29 that Git 2.55 builds with Rust enabled by default “unless opting out with the ‘NO_RUST’ option.” The document adds that the project will “evaluate the impact on downstream distributions” before making Rust mandatory and “may decide to defer this change to a subsequent minor release.”

For the hash change, the document names ecosystem readiness as a requirement: “popular Git libraries, applications and forges.” LWN reported on September 18 that SHA-256 support has been non-experimental since Git 2.42 in 2023. GitLab has had support since 2024 and Forgejo has it, but “the elephant that is still missing from this room, though, is GitHub,” and “it still is not clear when GitHub might add that support.” The same article says libgit2 “will not be a blocker.” An undated update to the LWN article says that, as described by Steinhardt at Kernel Recipes, the December 2026 release will be called 2.98 “as a signal that the 3.0 transition is coming,” with a long-term-support 2.99 and Git 3.0 in April 2027. A draft of the 2.98 release notes in Git’s repository calls that release “meant to be the antepenultimate release to prepare for the long anticipated Git 3.0”.

The timeline has moved. Phoronix reported on October 12, 2025 that Git 3.0 might arrive “before the end of 2026”; the plan LWN describes puts it in April 2027. Separately, the BreakingChanges document still says “There is no planned release date for this breaking version yet.” Nothing in the cited sources explains why the document and the LWN update differ, so both are reported as stated. The Herald’s earlier report on the 2.56 release candidate covers that release.

Implications

The following is the Herald’s reading of the three cases, not a finding of any cited source.

Where the notice lands differs. In LWN’s Rust example, the break shows up as a compile error: the code “causes a compilation error.” The warning appears in the compiler, while the crate scan and the backports targeted crates published on crates.io. In the Python case, the PEP itself says the failure can be silent, and the warning that would find affected code is opt-in, so finding affected code depends on a developer enabling it. In the Git case, three of the four defaults named above apply to new repositories, so the exposure sits mainly with the tools that read repositories and with those who build Git. LWN quotes brian m. carlson, a GitHub employee whom it describes as a key developer behind the SHA-256 transition, on JGit and Gitoxide, and says that after the Rust change “any platform that does not have a working Rust compiler will be unable to upgrade.”

Residual breakage is handled differently. Rust’s maintainers accepted some remaining breakage, and LWN lists staying on 1.99 among the options. Python kept a switch; on subprocess text mode, the PEP says: “Users can disable UTF-8 mode until they replace text=True with encoding=‘utf-8’ or encoding=‘locale’.” For Git, LWN reports that repositories using SHA-1 “will continue to be fully supported,” and the BreakingChanges document says there is “no plan to deprecate the ‘sha1’ object format at this point in time.”

The evidence behind the decision differs. In Rust’s case the decision drew on a measured count of affected public crates. For Python, the cited sources show a 2022 proposal, the warning added in 3.10 and no count of affected programs. For Git, the stated requirement is other people’s readiness, and the date has moved. None of the cited sources describes a scan of affected code across the ecosystem for Python or Git comparable to crater, though LWN quotes carlson as saying JGit and Gitoxide “were both informed that SHA-256 was coming in Git 3.0 at least a year ago.”

For developers, the cited sources point to concrete steps. For Rust: update dependencies, or add explicit types. For Python: run with -X warn_default_encoding and pass an explicit encoding. For Git: check whether the libraries and forges in use support SHA-256 and reftable and, for those who package Git, whether a Rust toolchain is available. The BreakingChanges document says the last version before Git 3.0 will be a long-term-support release that gets “important bug fixes for at least four release cycles and security fixes for six release cycles.”

What the sources do not settle

• How many Rust crates still fail after the backports. LWN gives the April crater counts and the 1,553 fixed crates, but no final tally.
• How much Python code relies on the locale default. PEP 686 gives no count.
• When GitHub will support SHA-256 repositories. LWN’s September 18 article calls it unclear, and the cited sources contain no later statement.
• Which Git 3.0 date holds, and whether Rust will in fact become mandatory in 3.0 or be deferred, as the BreakingChanges document allows.