Append `rc` or `unstable` to version tags of unstable versions
DerRockWolf opened this issue · comments
Unstable images are already tagged with additional tags identifying that they are unstable.
In addition it would be very useful, when using e.g. renovate bot for update automation, if the tags containing the version number would be suffixed with -rc or -unstable resulting in 1.35.0-rc instead of 1.35.0.
This would keep Renovate from bumping to unstable versions and would remove the need to manually check if the image is stable or not.
See https://busybox.net/ -- we use BusyBox upstream's version numbers verbatim, and they unfortunately do not differentiate unstable in any way more than it's usually the .0 release of a new minor.
Ok then I have to live with that unfortunately.
If release .0 is always unstable I at least can ignore the PRs.
Thanks for your help :)
Unfortunately the .0 tag is not always unstable. The current stable version is 1.35.0, as per the commit message on 1_35_stable branch.
It would be nice if busybox:latest was updated to be 1.35.0 when you have the time!
https://busybox.net/ still lists 1.35.0 as "unstable" and if you look historically on that page, the .0 is always unstable -- I think the 1_35_stable branch probably exists specifically so that a future 1.35.1 (stable) branch could be cut from it.
However, I do think that given the unique way that BusyBox uses the common "stable" and "unstable" terms, we probably should move latest to point to the latest version number (which as of #160 will be 1.36.0).
Full list of BusyBox website versions, for context:
$ wget -qO- 'https://busybox.net' | grep -ioE '[0-9a-zA-Z ]+ -- BusyBox [0-9.]+ [(](un)?stable[)]' | sed -re 's/(.*) -- (.*)/\2\t\1/' | column -ts$'\t' -R2
BusyBox 1.36.0 (unstable) 3 January 2023
BusyBox 1.35.0 (unstable) 26 December 2021
BusyBox 1.33.2 (stable) 30 November 2021
BusyBox 1.34.1 (stable) 30 September 2021
BusyBox 1.34.0 (unstable) 19 August 2021
BusyBox 1.33.1 (stable) 3 May 2021
BusyBox 1.32.1 (stable) 1 January 2021
BusyBox 1.33.0 (unstable) 29 December 2020
BusyBox 1.32.0 (unstable) 26 June 2020
BusyBox 1.31.1 (stable) 25 October 2019
BusyBox 1.31.0 (unstable) 10 June 2019
BusyBox 1.30.1 (stable) 14 February 2019
BusyBox 1.30.0 (unstable) 31 December 2018
BusyBox 1.29.3 (stable) 9 September 2018
BusyBox 1.29.2 (stable) 31 July 2018
BusyBox 1.29.1 (stable) 15 July 2018
BusyBox 1.29.0 (unstable) 1 July 2018
BusyBox 1.28.4 (stable) 22 May 2018
BusyBox 1.28.3 (stable) 3 April 2018
BusyBox 1.28.2 (stable) 26 March 2018
BusyBox 1.28.1 (stable) 15 February 2018
BusyBox 1.28.0 (unstable) 2 January 2018
BusyBox 1.27.2 (stable) 17 August 2017
BusyBox 1.27.1 (stable) 18 July 2017
BusyBox 1.27.0 (unstable) 3 July 2017
BusyBox 1.26.2 (stable) 10 January 2017
BusyBox 1.26.1 (stable) 2 January 2017
BusyBox 1.26.0 (unstable) 20 December 2016
BusyBox 1.25.1 (stable) 7 October 2016
BusyBox 1.25.0 (unstable) 22 June 2016
BusyBox 1.24.2 (stable) 24 March 2016
BusyBox 1.24.1 (stable) 24 October 2015
BusyBox 1.24.0 (unstable) 12 October 2015
BusyBox 1.23.2 (stable) 23 March 2015
BusyBox 1.23.1 (stable) 27 January 2015
BusyBox 1.23.0 (unstable) 23 December 2014
BusyBox 1.22.1 (stable) 20 January 2014
BusyBox 1.22.0 (unstable) 1 January 2014
BusyBox 1.21.1 (stable) 29 June 2013
BusyBox 1.21.0 (unstable) 21 January 2013
BusyBox 1.20.2 (stable) 2 July 2012Upon further consideration, I think we really ought to probably go even further here and no longer package "stable" and "unstable" but rather "latest major.minor" and "second-latest major.minor" (which today would give us 1.35.0 and 1.36.0 instead of 1.36.0 and 1.34.1, which is kind of a weird mix just because 1.34 happened to have a .1 release and 1.35 hasn't yet) but I'm not sure where that leaves us with the "stable" and "unstable" aliases. Perhaps they come and go based on whether our two releases are stable or unstable? (ie, we'd have busybox:unstable which would point to 1.36.0 but we would stop updating busybox:stable for now until there's a new .1 release)
https://busybox.net/ still lists 1.35.0 as "unstable" and if you look historically on that page, the .0 is always unstable -- I think the 1_35_stable branch probably exists specifically so that a future 1.35.1 (stable) branch could be cut from it.
I stand corrected!
However, I do think that given the unique way that BusyBox uses the common "stable" and "unstable" terms, we probably should move latest to point to the latest version number (which as of #160 will be 1.36.0).
As for where to point latest, there's plenty of precedent either way. For instance, ubuntu:latest currently points to ubuntu:22.04 because that's the latest LTS version.
Yeah, latest is a bit of a misnomer (that we as a container community can't really correct reasonably at this point) -- I interpret :latest not as "what's the latest release" but rather "what should I choose to use if I don't know what I need" which matches Ubuntu pointing to the latest LTS release instead of the latest rolling release.
I believe that what happened with 1.35 is that it turned out that 1.35.0 was plenty stable enough, so it never got a point release, so it never got a new tag. So, ironically, by being too stable it never got marked as stable.
Yeah,
latestis a bit of a misnomer (that we as a container community can't really correct reasonably at this point) -- I interpret:latestnot as "what's the latest release" but rather "what should I choose to use if I don't know what I need" which matches Ubuntu pointing to the latest LTS release instead of the latest rolling release.
By that measure busybox:latest should probably point to the highest numbered version that is either marked as stable or is on a branch that is marked stable and is more than <threshold age> old. Version 1.35.0 is more than a year old and as such is de facto stable. Once a branch is stable the Busybox team don't add any new functions, they just seem to do bug fixes.
FWIW, the CVE mentioned in #133 may result in a 1.35.1 being release; if so they might even mark it as stable!
Refactored in #161 👍