Three changes this week that need code changes, not just a version bump

Serguey Asael Shinder02 October 2026, 07:352 min read

Most releases ask only for a version bump. Three items from the last two days ask for more: each changes what correct code looks like, on a timeline that is easy to miss.

Quarkus 4: two months to find your problems. The first beta of Quarkus 4 arrived on 1 October, with the final release planned for the end of November. It moves to a new Java baseline, a new networking layer built around QUIC, and a new major version of Hibernate with Jakarta Persistence 4.0. The team says its migration guide is denser than usual and asks extension authors to start now. Teams running their own extensions are the ones most likely to break and have the least time to find out; the new 3.40 LTS gives them a stable line to stay on while they test. Source: https://quarkus.io/blog/quarkus-4-0-0-beta1-released

Rust 1.99: a pattern that compiles but should not be written. Alongside C-style variadic functions, Rust 1.99 updates the documentation of Box::leak to recommend against later freeing the leaked memory. The team says such code interacts badly with current and future compiler optimisations and becomes a particular problem once custom allocators are stabilised. Nothing breaks today, which is exactly why it is worth a search through the codebase now: Box::into_raw or Box::into_non_null are the recommended replacements. Source: https://blog.rust-lang.org/2026/10/01/Rust-1.99.0

GitHub: merging becomes asynchronous. GitHub's async merge API is now generally available and is the recommended way to merge pull requests from code, ahead of the synchronous REST endpoint and GraphQL mutations; it is also the only API that handles stacked pull requests. The change is in the error model: a merge request is accepted first and completes later, so bots have to poll for the outcome instead of trusting the first response. Source: https://github.blog/changelog/2026-10-01-github-async-merge-api-generally-available

The common thread. None of these forces anything this week. Each changes the default that new code will be written against, and each leaves old code working for now. That is the cheapest moment to adapt: before the beta becomes final, before custom allocators land, before the synchronous merge path is the one nobody maintains.