Repository navigation
Move regular releases after security release annoucement #1135
Description
I believe we should not perform other releases after a security releases has been announced.
- It's confusing for users if a release comes out before the expected security release date.
- It's a vulnerable release, it makes it unusable for users knowing it has vulnerabilities.
- It disrupts the tooling. In the security release process, the tool requires to know in which patch a vulnerability will be fixed, and which is vulnerable. If a new release comes after we declared it in the
vulnerabilities.json, it becomes inaccurate. It requires coordination.
I propose we delay regular releases to after the security release.
Activity
BethGriggs commentedon Dec 11, 2025
+1, particularly as security releases are kept specific to ease and lower the risk of adoption. If we ship a normal release in the meantime, that advantage is lost because users still have to adopt the larger release before getting the fix.
aduh95 commentedon Dec 11, 2025
Yeah logically we should release both 24.11.2 and 24.12.1, but that's simply not an option with the way we operate. If we do document this as a rule, we should probably include an exception for out-of-band patch releases (e.g. if the previous release contained an unforeseen breaking change we want to revert) just to not put ourselves in a position where the security releases would be unusable for the ecosystem.