On Mon, Feb 9, 2026 at 11:24 AM Evgeny Kotkov <[email protected]> wrote:
> Johan Corveleyn <[email protected]> writes: > > > ISTR that some packagers were not happy with our LTS vs. Regular > > release system, because it was too much work for them to pick up such > > a regular release if it wasn't supported for very long. So making this > > a regular release which we might only support for 6 months might mean > > that some packagers will ignore it. > > Branko Čibej <[email protected]> writes: > > > I think this LTS/regular distinction made sense for ... a few months? > > when there were enough active developers here to make it work. It would > > be better to say, e.g., each release will be supported for X years, with > > the current (N) and previous (N - 1) release always supported and the N-2 > > release receiving critical bug fixes. > > Nathan Hartman <[email protected]> writes: > > > Yeah I feel bad rocking the boat because I previously thought 1.15 > should be > > a regular release and my thinking has changed since then. tl;dr I think > 1.15 > > should be a LTS release... > > With the new responses in the thread, I think that Brane's suggestion could > address all of the mentioned problems. > > So let's say we revert to a unified release scheme without the LTS/regular > distinction. Essentially, every release would be treated as LTS, but with > a shorter support window (e.g., 3 years — to sync with Debian's full > support > cycle). > > This approach would: > > - Encourage packagers to pick up new releases, instead of postponing > adoption > until the next LTS release. > - Address the problem that we might not have enough resources for a steady > rate of non-empty regular releases every 6 months. > - Allow us to shift 1.14.x out of support 3 months after releasing 1.15.0. > - Return us to a proven model that worked well in the past. > - Address my personal concerns about unconditionally promising 4 years of > support for the first release (1.15.x) after a long break, which just > seems > too much in case there are problems. > > How does this sound? > > If we agree on this direction, the next action could be drafting a patch > that > updates our documentation and site, which would also be a better > illustration > of the new target state, and I could try to prepare it. > > > Thanks, > Evgeny Kotkov > In general, I support changing our release support structure to be a better fit for everyone. If I understand Evgeny's proposal correctly, it means: Starting with 1.15, all releases are supported for at least 3 years, or until 3 months after the next minor release, whichever is later. It would only support {N-1, N-2, ...} releases if they happened within the last 3 years (plus the 3 month overlap). After that, they become EOL. Is my understanding correct? FTR, I would be +1 to that. It seems a simple policy to explain and understand, and I think it's realistic. Cheers, Nathan
