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

Policy for supported OS/versions with instructions #788

Open
XSpielinbox opened this issue Apr 11, 2023 · 2 comments
Open

Policy for supported OS/versions with instructions #788

XSpielinbox opened this issue Apr 11, 2023 · 2 comments

Comments

@XSpielinbox
Copy link

The install instructions don't differentiate between versions for certain OS like Windows, Fedora or OpenBSD, but do for others like Ubuntu, Debian or CentOS.

It would be very nice, if there would be a clear policy, what OS and which versions of them are supported and on what basis they get (separate) install instructions.
This has been a mess for longer now as can be seen e.g. in #770 , #644 and #398.

At first glance i could not find any differences between the instructions for the different versions of one OS, where different version drop-downs are available.

I see the following options:

  1. one only has one drop-down per OS, without any version (backwards-compatibility of the links should be easy via redirects/rewrites), that if necessary include differences between versions in text-form within the instructions.
    This would make a much less cluttered and much less confusing drop-down menu. Perhaps it would be useful to add a notice at the top of each page, that only non-EOL OS versions or only the latest version are supported (whatever would be applicable for that specific OS). As the install instructions for different versions currently only have minor differences, if any at all, this would also seem very appealing to me.
  2. One has specific entries for each supported OS version. These should then be regularly updated, at least for LTS versions. Differences between versions would the just mean different texts depending on the selected drop-down.
    This would be more maintenance work, but make the supported OS versions more explicit and easier to understand, if the install instructions should differ very significantly between OS versions.
  3. If there is only one breaking change in the installation with one OS version, one could also have the hybrid option of "before this version/after this version". This would be a middle ground of the above two options.

Independent of that one should decide by what definition EOL of OS is defined: The "first" EOL of the full-support phase? The "last" EOL date of the last extended, payed support? Something in between?

Currently this is very confusing: e.g. Ubuntu 19 (whether this shall refer to 19.04 or 19.10) is EOL (standard support) for many years now, Extended Security Maintenance there is none and never was one. Ubuntu 16.04 has also reached EOL (standard support) years ago too, but still would be in payed for Exdended Security Maintenance. Ubuntu 22.04 LTS and Ubuntu 22.10 are not mentioned at all, even though they are the latest release (or latest LTS release respectively) and have been out for a year (half a year respectively) and both are still in standard support phase.

If I can help in any way with that, please reach out to me.

@alexzorin
Copy link
Collaborator

I emphatically agree with the approach you describe in (1). It's pointless for the instruction generator to chase the OS version treadmill, especially considering our instructions for Ubuntu, Debian and CentOS are all the same (use the Certbot snap).

Independent of that one should decide by what definition EOL of OS is defined: The "first" EOL of the full-support phase? The "last" EOL date of the last extended, payed support? Something in between?

I am not sure there is a useful hard line here. One can install Certbot on an EOL-ish distro from package archives (or even from snaps), and there's a good chance that it will work fine. Users are free to shoot themselves in the feet by continuing to run an EOL OS.

If something breaks in Ubuntu ESM, it's probably on Canonical to do something. If something breaks in Debian LTS, we'd probably try to do something, depending on how out of our hands the problem is.

I'd be OK with being vague here.

If I can help in any way with that, please reach out to me.

As mentioned at #398 (comment), another team needs to do this. @bmw is your current request just for Ubuntu or all of the duplicated distros? It looks like we can do:

  • Ubuntu
  • Debian
  • CentOS
  • Devuan
  • openSUSE

@bmw
Copy link
Member

bmw commented Apr 12, 2023

It's for all so I'll add a link to your comment that helpfully lists them. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants