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
