Optimize Ubuntu versioning

[HonkingGoose]

What would you like Renovate to be able to do?

Quote from @viceice:

I think we need a new issue to track Ubuntu versioning optimization.

We recently merged a "hacky" PR #12528 which makes it so we consider Ubuntu 22.04 unstable (right now this is released as a "early testing" build, not a proper stable release).

If you have any ideas on how this should be implemented, please tell us here.

How about we create a .json file and put the Ubuntu release schedule in it?

I got the idea from the Node.js schedule file that we used to mirror in the Renovate repository. ¹

Node.js schedule JSON example:

  "v16": {
    "start": "2021-04-20",
    "lts": "2021-10-26",
    "maintenance": "2022-10-18",
    "end": "2024-04-30",
    "codename": "Gallium"
  },

Possible JSON format for the Ubuntu versioning:

  "v20.04": {
    "initial-release": "2020-04-23",
    "initial-lts-release": "2020-04-23",
    "end-of-normal-support": "2025-04-23",
    "end-of-extended-security-maintenance": "2030-04-23",
    "codename": "Focal Fossa"
  },

I haven't found a schedule like this from Ubuntu themselves, at least not in a form that a computer can understand/parse. I did find a list of releases on the Ubuntu wiki though. ²

Is this a feature you are interested in implementing yourself?

No

Footnotes

1. https://github.com/nodejs/Release/blob/main/schedule.json ↩

2. https://wiki.ubuntu.com/Releases ↩

[HonkingGoose]

@rarkins what do you think of my idea to put the Ubuntu supported dates into a JSON file?

[rarkins]

Is such a file already published by Ubuntu anywhere?

[HonkingGoose]

There's a releases.yaml file that's in the canonical-web-and-design/ubuntu.com repository. ¹

I've checked the history of releases.yaml and they overwrite earlier Ubuntu versions. ²

The Node.js JSON file lists all prior versions of Node.js, which seems a safer route than clobbering over the history with new edits.

I'm not sure if the release.yml file is stable enough for us to use as a "source of truth". Can you take a look at the file and the edit history and see for yourself if we could use it safely?

Footnotes

1. https://github.com/canonical-web-and-design/ubuntu.com/blob/main/releases.yaml ↩

2. https://github.com/canonical-web-and-design/ubuntu.com/commit/5fb320f42924d8c16203187a7cbce98a9f572e2c#diff-2971fc0fc21c1f5ef410d394709e9dcd106c1dafc6360fbbdeec8457b638259d ↩

[viceice]

I think that file is good enough, as we only need to know which is lates lts and which are not eol.

[HonkingGoose]

We could copy/paste their releases.yml file into our repository, this way we keep control over the file. This means extra maintenance work, as we don't have a easy way right now to let Renovate sync the file (we do have a issue open somewhere for simple file syncing with Renovate) ¹.

Then after we've copy/pasted the file, we can change our Renovate code to refer to the releases.yml file when working on Ubuntu updates.

Let me know if this is the right course of action or not! 😉

Footnotes

1. Support new "file sync" manager #4759 ↩

[viceice]

Ok, we can't copy the releases.yml directly because of licensing.

What about download and convert to JSON on prepare /compile stage?

[rarkins]

I think it would be better if it can be transformed as part of the dev/build stage

[HonkingGoose]

Do we still need this issue?

It looks like we have code that generates a ubuntu-distro-info.json file based on information from these urls?

renovate/lib/modules/versioning/ubuntu/index.ts

Lines 8 to 11 in 2c087e8

	export const urls = [
	'https://changelogs.ubuntu.com/meta-release',
	'https://debian.pages.debian.net/distro-info-data/ubuntu.csv',
	];

renovate/lib/modules/versioning/ubuntu/index.ts

Line 14 in 2c087e8

const di = new DistroInfo('data/ubuntu-distro-info.json');

renovate/data/ubuntu-distro-info.json

Lines 260 to 268 in 2c087e8

	"v22.04": {
	"codename": "Jammy Jellyfish",
	"series": "jammy",
	"created": "2021-10-14",
	"release": "2022-04-21",
	"eol": "2027-04-21",
	"eol_server": "2027-04-21",
	"eol_esm": "2032-04-21"
	}