Before answering your other questions, I want to first clarify that our intended release frequency isn’t changing with this proposal.
- For the past 3 years, we’ve been making “stable” releases approximately every 6 months, targeting these releases for the end of each January and July, with a bit of slippage here and there:
- For the past ~8 months, we’ve been making “beta” releases approximately every month, aside from a couple of out of band security releases:
- 3.5.0-beta1: 2025 Feb 24
- 3.5.0-beta2: 2025 Mar 25
- 3.5.0-beta3: 2025 Apr 29
- 3.5.0-beta4 2025 May 5 (out of band security release)
- 3.5.0-beta5: 2025 May 28
- 3.5.0-beta6 (out of band security release)
- 3.5.0-beta7: 2025 Jun 24
- 3.5.0-beta8: 2025 Jul 28
In this new proposal, we intend to keep the same cadence we’ve been following, with the main changes being:
- What we now call “stable” releases, we’ll be calling “extended support releases”
- We’ve chosen that name and not long term support, because we agree that it’s extended relative to our other supported releases, but not necessarily “long term”. This proposal doesn’t include adding a long term support release.
- Currently, support for one stable release ends immediately when the next release is made. With this new proposal, support overlaps for ~2 months, so people have time to upgrade while receiving security patches
- What we now call “beta” releases, we’ll be calling “releases”
- We don’t currently support beta releases at all beyond their release date. They are merely checkpoints along the way that come with a notification to fast forward, as they also often include security fixes
- With this proposal we do intend to support releases for ~2 months, so people can decide when to upgrade, while continuing to receive security patches
With that in mind, do you feel like your other questions about too many settings are still related to this proposal? Or are they independent concerns that would be better to discuss in a separate topic?