You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
I pondered a lot about the best place to discuss this
I will be at FOSDEM and will very happily discuss this in-person
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:
due to the long-term maintenance needs, we stick to LTS releases unless we
are sure there will be another openssl LTS by the next Ubuntu LTS
the openssl team will have to maintain concurrently many releases
I'm wondering about the audience for interim releases that are maintained for
2 years but released every 6 months
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.
Years
0
0.5
1
1.5
2
2.5
3
3.5
4
4.5
5
5.5
6
6.5
7
7.5
8
8.5
9
9.5
LTS
██
██
██
██
██
██
██
██
░░
░░
LTS
██
██
██
██
██
██
██
██
░░
░░
LTS
██
██
██
██
Interim
██
░░
░░
Interim
██
██
░░
░░
Interim
██
██
░░
░░
Interim
██
██
░░
░░
Interim
██
██
░░
░░
Interim
██
██
░░
░░
Interim
██
██
░░
░░
Interim
██
██
░░
░░
Interim
██
██
░░
░░
(LTS)
Interim
██
██
░░
░░
Interim
██
██
░░
░░
Interim
██
██
░░
░░
Interim
██
██
░░
░░
Interim
██
██
░░
░░
Interim
██
██
░░
░░
Interim
██
██
░░
░░
Interim
██
██
░░
░░
...
Concurrent
3
4
5
5
5
5
5
5
5
5
4
4
5
5
5
5
5
5
4
4
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
Years
0
0.5
1
1.5
2
2.5
3
3.5
4
4.5
5
5.5
6
6.5
7
7.5
8
8.5
9
9.5
LTS
██
██
██
██
██
██
██
██
░░
░░
LTS
██
██
██
██
██
██
██
██
░░
░░
LTS
██
██
██
██
██
██
██
██
░░
░░
LTS
██
██
██
██
██
██
██
██
LTS
██
██
██
██
Interim
░░
Interim
██
░░
Interim
██
░░
Interim
██
░░
Interim
██
░░
(LTS)
Interim
██
░░
Interim
██
░░
Interim
██
░░
(LTS)
Interim
██
░░
Interim
██
░░
Interim
██
░░
(LTS)
Interim
██
░░
Interim
██
░░
Interim
██
░░
(LTS)
...
Concurrent
3
3
3
3
3
3
4
4
4
4
4
4
4
4
4
4
4
4
4
4
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.
The text was updated successfully, but these errors were encountered:
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.
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:
are sure there will be another openssl LTS by the next Ubuntu LTS
2 years but released every 6 months
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.
The text was updated successfully, but these errors were encountered: