2 ms·
> codes are not sticky / spanned so to know what sort of changes you should expect between two versions you have to look at every intermediate. The only change
by kstenerud 7y ago
> codes are not sticky / spanned so to know what sort of changes you should expect between two versions you have to look at every intermediate.
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.
- naniwaduni 7y agoHow are you going to relabel it when you can't yank it?
- kstenerud 7y agoYou 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 Bad release you can't yank: 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 Now everyone knows that 2.2020.01.01.3 is bad but couldn't be yanked.
- masklinn 7y ago> 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.