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
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.