Open adrien-n opened 5 months ago
hlandau
commented
5 months ago Thanks for the thoughtful writeup. It is definitely on our radar that our LTS strategy will need adjusting with the move to time-based releases and we hope to discuss it in the coming months.
arapov
commented
5 months ago Yes, thanks @adrien-n. You will find me at Fosdem at our booth - I will be happy to discuss this.
adrien-n
commented
5 months ago Oh, I didn't know you had a booth there. I'll definitely stop by. :)
Dear Maintainers,
I maintain the openssl package in Ubuntu. While doing so, I had many occasions to reflect on the openssl release schedule. I discussed updates a few months ago with some people of the team on launchpad and I'm really doing all I can in order to make it better for everyone but users often have incompatible wishes.
NB:
The new release schedule seems very promising but I also have several concerns with the current release schedule which I think can be fairly easily improved:
I'm bringing that up now specifically because Ubuntu 24.04 will still be using 3.0.(latest) unless openssl 3.3 is an LTS (and I arrange for some extra things due to both ubuntu and openssl releasing in April with beta/RC phases). We discussed this a lot and couldn't find another way. This also made me think a lot about the release schedules.
I made a pretty markdown+unicode table/graph in order to explain this. The Years line (the first one) gives the time in terms of half-years, starting from an arbitrary point. Full-color blocks indicate full support while shaded ones indicate security-only maintenance. LTS and Interim releases are grouped separately due to their different schedule. The "total" line at the bottom counts how many releases are supported at the same time.
The first table uses the current release schedule. Except for the first year or so, there will often be 5 releases supported at the same time, sometimes 4, for an average of 4.75 in steady state.
I believe that the two year support for interim releases is more than needed because people who are interested in such a duration are probably using LTS releases instead, while people who upgrade more frequently are ready to update every 6 or 12 months.
On the other hand, an LTS every two years would be very helpful and would help updating tremendously, all while keeping the number of concurrently-supported versions lower than with the current schedule thanks
Another option could be to keep the same duration for maintenance of interim releases but release every 12 months instead. I don't think that aligns with the current goals which probably include releases of a manageable size. (and I don't want to do another markdown table!).
Do you have opinions on this? I genuinely believe these are small changes that will be helpful to everyone, especially in the long run.
Thanks.