Re:Chronologic Versioning: No more arbitrary version updates...
by masklinn on Thursday January 02, 2020 @03:30PM
(#21939458)
> The only changes people usually care about are "will it break my software?" and "Am I using deprecated calls?"
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.
Re:Chronologic Versioning: No more arbitrary version updates...
by naniwaduni on Thursday January 02, 2020 @08:20AM
(#21935100)
How are you going to relabel it when you can't yank it?
Re:Chronologic Versioning: No more arbitrary version updates...
by kstenerud on Thursday January 02, 2020 @08:44AM
(#21935257)
You don't. You create a second "marker" release whose only purpose is to announce to the world that this release is bad.
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
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.