Meaning the tag is useless. If a release is “bad” you just yank it.
> it will show up as after 2.2020.1.1.3-bd
According to your scheme the last number is the release index in the day so this is nonsense: either -z replaces -bd or it’s a later release which appears before in the release list (assuming you have a descending alphanumeric sort).
You wouldn’t have both 2.2020.1.1.3-bd and 2.2020.1.1.3-z because they’re the same release with different crap tacked on.
The only changes people usually care about are "will it break my software?" and "Am I using deprecated calls?" Beyond that, there's no standardized way to know what has changed between releases, and you'd have to look at every release regardless. Of course we could always add another metadata letter "n" to signify "new features". In fact, I'll add it...
> If a release is “bad” you just yank it.
And what if you can't yank it? That's what the "z" tag is for. If you can yank it then by all means yank it.
Which is exactly what your scheme does not answer unless you go through every single version between current and latest one by one, at which point… what’s the point if your scheme? You’re going through every single version anyway you can explicitely list the changes.
> And what if you can't yank it?
Then you add support for yanking.
Example:
Current release list:
...
2.2019.12.18.1
2.2019.12.19.1-n
2.2019.12.19.2
2.2020.01.01.3-bd
Create a new marker release: 2.2020.01.01.3-z
New release list:
...
2.2019.12.18.1
2.2019.12.19.1-n
2.2019.12.19.2
2.2020.01.01.3-bd
2.2020.01.01.3-z
A better approach would be hybrid:
2.2020.01.01.3-bd
Where the first number is the release track, the next three are the date, the last number is to handle multiple releases in a day, and the letters (always in alphabetical order) are codes for:
b: this is a breaking change
d: there are deprecations in this release
I would also suggest a third letter code "z" to mark bad releases, where you unintentionally broke things to the point that this release should not be used (and for whatever reason cannot retract the release). So, to mark the above release as bad, tag the exact same version a second time:
2.2020.01.01.3-z
Which means that 2.2020.01.01.3 is a bad release. It will show up after 2.2020.01.01.3-bd because it's later in the alphabet in the release list. Anyone looking for the last release that matches whatever their criteria is will now know to avoid that particular version.
Edit: Formalized here: https://github.com/kstenerud/hyver