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

ci: remove ubuntu 22.04 job #9707

Closed
wants to merge 1 commit into from

Conversation

tobtoht
Copy link
Collaborator

@tobtoht tobtoht commented Jan 15, 2025

Assumes #9680.

The Ubuntu 22.04 job is a little redundant now that we have a job for a bleeding-edge Linux distro (Arch Linux). Builds failing due to package upgrades will most likely get caught by this run.

@iamamyth
Copy link

Couldn't you make a similar argument for debian 10 and ubuntu 20? If anything, I'd rather keep ubuntu 22 than 20, as it's quite a popular distro (in effect making the test matrix: upcoming, common/popular base, and oldest).

@tobtoht
Copy link
Collaborator Author

tobtoht commented Jan 15, 2025

The jobs for Debian 10 and Ubuntu 20.04 serve a specific purpose: to ensure we don't accidentally break development builds on the oldest supported distributions. Due to how EOL policies line up, Debian does not always have the oldest packages, so it's important to keep both.

The most recent packages are covered by the bleeding edge job. Build issues with recent packages can be fixed before they land in more recent Ubuntu versions.

I don't know where 22.04 fits in here. If we want to keep it, we should define a deprecation policy, so it's clear to (future) maintainers when it should be removed/upgraded.

@iamamyth
Copy link

Due to how EOL policies line up, Debian does not always have the oldest packages, so it's important to keep both.

I had forgotten Ubuntu sometimes ends up with older packages than the roughly equivalent Debian version.

I don't know where 22.04 fits in here

Ubuntu 22.04 was the "common/popular" part of the test matrix from my earlier comment; maybe that should now be 24, but it seems a bit too recent to have more users than 22. I can see a case for eliminating it to save build time, but theoretical backwards-compat doesn't always translate to reality (compilers especially like to break things). As for update timelines, particularly if there's an Arch build, I'd guess 1-2 years after a new LTS distro gets released, rounding up to two; perhaps we can find some data to better inform the decision, if we want to keep it.

@iamamyth
Copy link

Here are some initial stats on Ubuntu usage:
https://fr.archive.ubuntu.com/stats/stats_of_day-24.html?version=last
https://fr.archive.ubuntu.com/stats/stats_of_day-406.html?version=last

So, ~1.6 years after 22 was released, it easily eclipsed 20, whereas 24 had virtually no usage 7 months after release. I'd say the next LTS becomes the "most popular" after 18 months maybe?

@selsta
Copy link
Collaborator

selsta commented Jan 15, 2025

I think it does not hurt to keep it if it adds a different compiler version compared to the other CI jobs.

@tobtoht
Copy link
Collaborator Author

tobtoht commented Jan 15, 2025

I think 'most recent LTS + 18 months' is a reasonable deprecation guideline. We can evaluate at that time if a newer version has indeed eclipsed the older version in usage. This will also give us a decent spread of compiler versions.

OS Purpose Deprecation Policy Date GCC
Debian 10 Oldest 9446 or later > 30 Jun 2025 8.3.0
Ubuntu 20.08 Oldest 9446 or later > 02 Apr 2026 9.4.0
Ubuntu 22.04 Popular Most recent LTS + ~18 m ~ Nov 2025 11.4.0
Arch Linux Newest Never - (14)

I'll likely follow up with a PR to document this.

@tobtoht tobtoht closed this Jan 15, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants