Move regular releases after security release annoucement

[marco-ippolito]

I believe we should not perform other releases after a security releases has been announced.

1. It's confusing for users if a release comes out before the expected security release date.
2. It's a vulnerable release, it makes it unusable for users knowing it has vulnerabilities.
3. 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.

[BethGriggs]

+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]

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.