feat(versioning/debian): Debian codenames support

[Gabriel-Ladzaretti]

Changes

Added dedicated versioning for Debian by extending dockerVersioningApi.
Supports debian codenames.

IMO it shouldn't be. I know I commented that we should cover Debian release names, but it should be a separate PR. There is some added complexity with Debian and it's naming of stable, oldstable, oldoldstable, etc.

#14601 (comment)

Context

• Closes Support Debian codenames #14774
• Blocked by refactor(versioning/distro-info): for future use in debian and ubuntu versioning #14880
• Blocked by refactor(versioning/distro): added functionality for debian  #15051
• Blocked by refactor(versioning/distro): Move date handling into distro.ts #15271

Documentation (please check one with an [x])

• I have updated the documentation, or
• Documentation update is required

How I've tested my work (please tick one)

I have verified these changes via:

• Code inspection only, or
• Unit tests added
• No unit tests but ran on a real repository, or
• Both unit tests + Ran on a real repository

[Gabriel-Ladzaretti]

Example run on real repo.
work in progress as its suggests upgrading to a testing release.

@JamieMagee @viceice
Would getting and extracting Index of releases from https://www.debian.org/releases/ could be a valid solution for getting the oldstable etc. info ?

[rarkins]

I think the main thing we need to know is "what is the stable release of Debian"? To us both testing and unstable are considered unstable. Ideally there was a better way of getting that info.

Does Debian have a "schedule" anywhere where they document intent to promote a certain version to stable in the future? E.g. like node.js does

[viceice]

also please Split the Ubuntu refactoring from this new feature to a separate PR.

[JamieMagee]

There's not a clean API or schedule of sorts. The reference for most of this info is going to be these pages:

• https://www.debian.org/releases/
• https://wiki.debian.org/DebianReleases

They give future EOL dates to the month.

@Gabriel-Ladzaretti I think the wiki might be a slightly better option? But not by much. Equally, they change every 2 years 🤷

The special cases we need to handle are:

• stable -> bullseye
• oldstable -> buster
• oldoldstable -> stretch
• testing -> bookworm
• unstable -> sid

[JamieMagee]

Actually, with a bit more digging, this is the source for debian-info-data and ubuntu-info-data:

• https://debian.pages.debian.net/distro-info-data/debian.csv
• https://debian.pages.debian.net/distro-info-data/ubuntu.csv

[Gabriel-Ladzaretti]

@JamieMagee @viceice @rarkins
Example renovate pull request.
not quite sure if we should offer upgrades to rolling updates i.e. stable etc...

[HonkingGoose]

Blocked by #14880

I see this is listed in your top post, is still still blocking us?

[Gabriel-Ladzaretti]

Blocked by #14880

I see this is listed in your top post, is still still blocking us?

Not the cleanest way of doing things, but i was working on both PR simultaneously as the refactor came out to be because of this one. so i am cherry picking changes back and forth.
so this actually contains the refactor.
but then again it is most probably better to first merge and close the refactor pr.

[JamieMagee]

not quite sure if we should offer upgrades to rolling updates i.e. stable etc...

You mean like oldoldstable to stable? I think it makes sense. oldoldstable is still rolling. As long as we're not moving users from a named release (bullseye) to a rolling release (stable).

[viceice]

Please extract the refactorings from this PR, so we can merge those first.

[Gabriel-Ladzaretti]

Blocked by -

• refactor(versioning/distro): Move date handling into distro.ts #15271

[renovate-release]

🎉 This PR is included in version 32.63.0 🎉

The release is available on:

• GitHub release
• 32.63.0

Your semantic-release bot 📦🚀