Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve release cadence and support duration #60

Open
adrien-n opened this issue Jan 17, 2024 · 3 comments
Open

Improve release cadence and support duration #60

adrien-n opened this issue Jan 17, 2024 · 3 comments
Assignees

Comments

@adrien-n
Copy link

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:

  • 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.

@arapov arapov self-assigned this Jan 17, 2024
@hlandau
Copy link
Member

hlandau commented Jan 18, 2024

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
Copy link
Member

arapov commented Jan 18, 2024

Yes, thanks @adrien-n. You will find me at Fosdem at our booth - I will be happy to discuss this.

@adrien-n
Copy link
Author

Oh, I didn't know you had a booth there. I'll definitely stop by. :)

@arapov arapov assigned nhorman and unassigned arapov Mar 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: To do
Development

No branches or pull requests

4 participants