Kubernetes v1.36 enters code freeze

Kubernetes is the traffic system for containerized apps: it decides which machine runs each app, restarts crashed pieces, and exposes them on the network. Every three or four months, that traffic system gets a new minor release, and each release moves through a calendar with freezes that gradually stop risky changes from landing. (kubernetes.io) A code freeze is the point where Kubernetes stops taking ordinary new code for that release and narrows the gate to bug fixes and failing-test work. The official release-process guide says the freeze period lasts about four weeks before final release, and pull requests during that window need stricter labels and milestone targeting. (kubernetes.io) For version 1.36, that code freeze and test freeze hit on Wednesday, March 18, 2026, in Anywhere on Earth time, which is the last place on the planet to finish the day. Kubernetes uses that time standard so contributors in California, Berlin, and Tokyo all work against one deadline instead of arguing over midnight. (kubernetes.dev) The next gate is documentation freeze, which the 1.36 calendar set for Wednesday, April 8, 2026 AoE, or Thursday, April 9, 2026 at 12:00 Coordinated Universal Time. That is the point where docs, release notes, and user-facing explanations need to stop shifting so the project can package a stable release. (kubernetes.dev) The target release date for Kubernetes 1.36 is Wednesday, April 22, 2026, which puts the project in the final stretch right now. In practice, this is the stage where release managers are watching test signal, pruning anything unstable, and turning a moving codebase into something people can actually upgrade to. (kubernetes.dev; kubernetes.io) The patch and prerelease tags posted alongside this phase tell you which train you are looking at. The Kubernetes GitHub releases page shows version 1.36.0-beta.0 as a prerelease from about three weeks ago, and it also shows version 1.35.3 as the latest patch in the current stable 1.35 line from the same period. (github.com) Those two version numbers do different jobs. Version 1.36.0-beta.0 is a preview of the next minor release for testing new behavior before general availability, while version 1.35.3 is a patch release for people who want fixes without taking on the bigger surface area of a new minor version. (github.com; kubernetes.io) Kubernetes only maintains active patch branches for the most recent three minor releases, and the releases page currently lists 1.35, 1.34, and 1.33 as those supported lines. That means platform teams deciding between 1.35.3 and the coming 1.36.0 release are not choosing in a vacuum; they are choosing which supported branch they want to live on for the next year of patches. (kubernetes.io) Patch releases also run on their own monthly train, which is why 1.35.3 can ship while 1.36 is still freezing. The official patch-release schedule says April 2026 has a cherry-pick deadline of April 10 and a target patch release date of April 14, so bug fixes for stable branches keep moving even while the new release is being locked down. (kubernetes.io) If you are running a cluster, the practical reading is simple: test version 1.36 against your add-ons now, but keep production on the latest 1.35 patch until the April 22 release and its upgrade notes are in front of you. The 1.36 sneak-peek post says the release includes removals, deprecations, and a large set of enhancements, which is exactly the kind of mix that rewards a dry run before you touch a live control plane. (kubernetes.io; kubernetes.dev)