3 ms·

1) people would abuse the versions system you described as well. Very stable software that does not include breaking changes would always stay on the same "year

1) people would abuse the versions system you described as well. Very stable software that does not include breaking changes would always stay on the same "year" version and they'd feel tempted to bump the year even with not breaking changes. Same for the other way around, people that don't want to wait for the year to end would include breaking changes on a stable release without bumping the year because even if the changes are breaking, they've been tested and are stable. 2) if you are following the guidelines properly, 3.4.1 and 3.8.4 means that there were no breaking changes, that's all I wanna know from a version tag. If I wanna know more, I'll look at the changelog, which I'd look either way regardless of versioning scheme. 3) how to get from 3.4.1 to 3.8.4: again, if people are following the guidelines, you just bump the version because there are no breaking changes. 4) I don't understand your point here. But you can also have non stable versions in semantic version, like 1.2.3-rc1.

KronisLV 5y ago
> Very stable software that does not include breaking changes would always stay on the same "year" version and they'd feel tempted to bump the year even with not breaking changes. Same for the other way around, people that don't want to wait for the year to end would include breaking changes on a stable release without bumping the year because even if the changes are breaking, they've been tested and are stable. In my eyes, that's the beauty behind that idea: you can bump the year, if you want to create a new version (e.g. corporate policy, a LTS released every X years) even without major changes, but that's essentially another offshoot of the codebase that you have to maintain. This might make you reconsider whether that's worth doing and what your EOL policy is. Similarly, the system would disallow stable versions more than once a year, which i'd view as a feature, instead of a shortcoming. I'd argue that humans probably have a cognitive limit in regards to dealing with the frequency of updates, so a year seems like a decent limitation to set, especially given how many dependencies (e.g. versions) most software out there has to deal with. > If you are following the guidelines properly, 3.4.1 and 3.8.4 means that there were no breaking changes, that's all I wanna know from a version tag. If I wanna know more, I'll look at the changelog, which I'd look either way regardless of versioning scheme. I'd argue that version tags should contain more information, rather than just a reference to which other versions would be compatible. That's definitely not all that i care about. I'd also like to suggest that looking at changelogs isn't feasible with limited resources or lots of dependencies. For example, i have the following dependency versions in a prod application: 2.8.8 3.0.0 10.2.0 3.9.4 6.1.2 ... (not included: another 45 dependencies) Corporate asks me to update everything that's older than 2 years. The version numbers don't help me in this regard, at a glance. Thus, i'm forced to look up the releases either with a tool to check how old the versions are and what updates exist for the same MAJOR version, or i'm forced to do so manually, especially if i don't have the engineering time to find an automatic solution (and which no one has done so in the past due to a lack of buy-in to spend engineering time on this). I also probably can't update everything automatically to the latest MINOR or even PATCH version, because some of the dependencies deal with core functionality that doesn't always have unit tests, so figuring out what breaks what must be done with gradual updates and code fixes (i dislike how little other people care for striving towards 100% test coverage, but this is also the objective reality that i'm dealing with). Contrast that with the following: 2021-stable-5 2021-latest-13 2021-stable-2 2018-latest-41 2014-stable-81 ... (not included: another 45 dependencies) That'd instantly give me hints about how old what is, even in the worst case scenario of no tooling for automation, or no opportunities to use any. Furthermore, "latest" would probably need more attention paid to it than "stable", e.g. the "2018-latest-41" might be upgraded to the corresponding "stable" version. > If people are following the guidelines, you just bump the version because there are no breaking changes. My argument is that this doesn't happen (reliably enough) and everything we can do to limit accidental breakages is probably a good idea. If we remove the MINOR versions altogether, that already eliminates a class of suspicious code changes: "new non-breaking features", at least in my experience, is a misnomer, since i've definitely seen such attempts break things anyways. That's a risk i don't want to take outside of planned major version upgrades. For example, if you have a merge request against a branch "2014-stable" in your VCS (assuming the branch names correspond to versions) that contains a new feature, you know that it's probably wrong and doesn't belond in your next maintenance release. New features belong in the "latest" versions, equivalent to what you'd get with "trunk" or "nightly" versions, if you want to live on the bleeding edge and do rolling releases. They should only make their way into stable versions after being properly tested, without backporting being done - only bugfixes and security fixes should be backported. > But you can also have non stable versions in semantic version, like 1.2.3-rc1 And yet, that's not the default and therefore isn't done in most of the packages out there. Including such metadata in the default version format has its benefits in my eyes, e.g. you know whether you're about to use something bleeding edge, or something that's more stable. For example, the long term updates that MySQL 5.7 received is a good litmus test for stability in my eyes, it has been updated from 2013 all the way to 2021: https://dev.mysql.com/doc/relnotes/mysql/5.7/en/ https://dev.mysql.com/doc/relnotes/mysql/5.7/en/ If i saw "2013-stable-..." be released in 2021, then i'd instantly know that the dependency passes this test of mine and that probably newer versions will also maintain long term support. It's a bit odd, that software packages don't always have clearly defined EOL policies, like OSes do: https://endoflife.software/operating-systems/linux https://endoflife.software/operating-systems/linux

KronisLV 5y ago

> Very stable software that does not include breaking changes would always stay on the same "year" version and they'd feel tempted to bump the year even with not breaking changes. Same for the other way around, people that don't want to wait for the year to end would include breaking changes on a stable release without bumping the year because even if the changes are breaking, they've been tested and are stable. In my eyes, that's the beauty behind that idea: you can bump the year, if you want to create a new version (e.g. corporate policy, a LTS released every X years) even without major changes, but that's essentially another offshoot of the codebase that you have to maintain. This might make you reconsider whether that's worth doing and what your EOL policy is. Similarly, the system would disallow stable versions more than once a year, which i'd view as a feature, instead of a shortcoming. I'd argue that humans probably have a cognitive limit in regards to dealing with the frequency of updates, so a year seems like a decent limitation to set, especially given how many dependencies (e.g. versions) most software out there has to deal with. > If you are following the guidelines properly, 3.4.1 and 3.8.4 means that there were no breaking changes, that's all I wanna know from a version tag. If I wanna know more, I'll look at the changelog, which I'd look either way regardless of versioning scheme. I'd argue that version tags should contain more information, rather than just a reference to which other versions would be compatible. That's definitely not all that i care about. I'd also like to suggest that looking at changelogs isn't feasible with limited resources or lots of dependencies. For example, i have the following dependency versions in a prod application: 2.8.8 3.0.0 10.2.0 3.9.4 6.1.2 ... (not included: another 45 dependencies) Corporate asks me to update everything that's older than 2 years. The version numbers don't help me in this regard, at a glance. Thus, i'm forced to look up the releases either with a tool to check how old the versions are and what updates exist for the same MAJOR version, or i'm forced to do so manually, especially if i don't have the engineering time to find an automatic solution (and which no one has done so in the past due to a lack of buy-in to spend engineering time on this). I also probably can't update everything automatically to the latest MINOR or even PATCH version, because some of the dependencies deal with core functionality that doesn't always have unit tests, so figuring out what breaks what must be done with gradual updates and code fixes (i dislike how little other people care for striving towards 100% test coverage, but this is also the objective reality that i'm dealing with). Contrast that with the following: 2021-stable-5 2021-latest-13 2021-stable-2 2018-latest-41 2014-stable-81 ... (not included: another 45 dependencies) That'd instantly give me hints about how old what is, even in the worst case scenario of no tooling for automation, or no opportunities to use any. Furthermore, "latest" would probably need more attention paid to it than "stable", e.g. the "2018-latest-41" might be upgraded to the corresponding "stable" version. > If people are following the guidelines, you just bump the version because there are no breaking changes. My argument is that this doesn't happen (reliably enough) and everything we can do to limit accidental breakages is probably a good idea. If we remove the MINOR versions altogether, that already eliminates a class of suspicious code changes: "new non-breaking features", at least in my experience, is a misnomer, since i've definitely seen such attempts break things anyways. That's a risk i don't want to take outside of planned major version upgrades. For example, if you have a merge request against a branch "2014-stable" in your VCS (assuming the branch names correspond to versions) that contains a new feature, you know that it's probably wrong and doesn't belond in your next maintenance release. New features belong in the "latest" versions, equivalent to what you'd get with "trunk" or "nightly" versions, if you want to live on the bleeding edge and do rolling releases. They should only make their way into stable versions after being properly tested, without backporting being done - only bugfixes and security fixes should be backported. > But you can also have non stable versions in semantic version, like 1.2.3-rc1 And yet, that's not the default and therefore isn't done in most of the packages out there. Including such metadata in the default version format has its benefits in my eyes, e.g. you know whether you're about to use something bleeding edge, or something that's more stable. For example, the long term updates that MySQL 5.7 received is a good litmus test for stability in my eyes, it has been updated from 2013 all the way to 2021: https://dev.mysql.com/doc/relnotes/mysql/5.7/en/ https://dev.mysql.com/doc/relnotes/mysql/5.7/en/ If i saw "2013-stable-..." be released in 2021, then i'd instantly know that the dependency passes this test of mine and that probably newer versions will also maintain long term support. It's a bit odd, that software packages don't always have clearly defined EOL policies, like OSes do: https://endoflife.software/operating-systems/linux https://endoflife.software/operating-systems/linux