Four ways this week's projects changed things without breaking users
Serguey Asael Shinder2 min readEvery release is a small bet that nothing important will break. This week's notes show four different ways projects hedged that bet, and they are worth comparing because each fits a different kind of change.
Flags and identical snapshots. GitHub's move from CSS-in-JS to CSS Modules touched every component on the site. Each change went behind a feature flag, visual regression tests had to show identical snapshots between old and new styles, and rollout went from the team to staff to everyone. A wrapper library kept old usage working while new code used the new path. Even removing the final dependency was flagged.
Named, opt-in previews. uv 0.12.19 introduced two behaviours - leaner lockfiles and lazy imports for build hooks - as preview features with names. Nothing changes until a project enables one, and a team can try it on a single repository before committing.
Say exactly what breaks. Tauri 2.12 raised the minimum Gradle version to 8.13 for Android projects in order to support Kotlin 2.x. That can break a build, so the release notes say which file to delete and which command to rerun.
Call a regression a regression. Crystal 1.21.1 marks its fix to Channel#tap with a [regression] label, separate from [security] entries. A reader can see at a glance what used to work, stopped working, and works again.
Which to use when
The four are not interchangeable. Flags and snapshot comparison suit changes whose correctness can be observed - here, the page must look the same - and where you control the whole deployment. Named previews suit tools used by many independent projects, where the maintainer cannot roll out gradually and users must choose. Explicit breakage notes suit changes forced by an ecosystem, like a build tool minimum, where there is no way to avoid breaking some users. And honest labels cost nothing and help everyone else decide how urgently to upgrade.
The common factor is that none of them relies on nobody noticing. Each makes the change visible to the people who might be affected, in the form they can act on - which is a better description of "backwards compatible" than any version number.