2 ms·

The distinction between minor and patch in semver appears untenable to me. Say 1.1.0 adds a new function, and 1.1.1 fixes a bug in an old function. I write som

by twic 5y ago

The distinction between minor and patch in semver appears untenable to me. Say 1.1.0 adds a new function, and 1.1.1 fixes a bug in an old function. I write some code which uses both functions, and would hit the bug before 1.1.1. This code has to be used with >=1.1.1, or it won't work. If it's used with something <1.1.0, it won't compile, and if it's used with 1.1.0, it will compile but not work; the distinction between those clearly isn't significant. So in practice, 1.1.0 -> 1.1.1 is as meaningful an increment as 1.0.0 -> 1.1.0. Semver would have been better with just major and minor versions.

Karellen 5y ago
You might not actually hit the bug in the old function. It may be that the function only has an error if the caller passes `argc = 0`, but there's no way your code will ever call that function that way. Bug fixes tend to be for weird edge cases. If the normal functionality doesn't work, someone would probably have noticed for the 1.0.0 release, or at least before the 1.1.0 release. And most of the time callers not only don't hit, but will never hit, the weird edge cases - that's what make them weird edge cases. That said, given enough users, Hyrum's Law comes into effect where not only do some small percentage of users hit your weird edge-case bugs, but a small percentage of those end up relying on them.
ergl 5y ago
If the maintainers have a good back-porting policy, they'd also put out a new 1.0.X release so that users of <1.1.0 can upgrade and get the fix without also getting the new function in 1.1.0. This is something that Apple sometimes does for security updates on macOS: they'll release a new patch version on all supported versions.
epage 5y ago
I feel minor vs patch is useful for communicating and for the psychological effect. Most people won't care about adding a stray function for one person. Major new functionality is different. Yes, this mixes "sentimental versioning" in with semver. People tend to rate limit their major and minor versions, waiting until they get enough changes to "justify" it. While this can have a negative effect for small additions, I think its good to rate limit deprecations which are important for minimizing the impact of breaking changes.

by twic 5y ago

Karellen 5y ago

You might not actually hit the bug in the old function. It may be that the function only has an error if the caller passes `argc = 0`, but there's no way your code will ever call that function that way. Bug fixes tend to be for weird edge cases. If the normal functionality doesn't work, someone would probably have noticed for the 1.0.0 release, or at least before the 1.1.0 release. And most of the time callers not only don't hit, but will never hit, the weird edge cases - that's what make them weird edge cases. That said, given enough users, Hyrum's Law comes into effect where not only do some small percentage of users hit your weird edge-case bugs, but a small percentage of those end up relying on them.

ergl 5y ago

If the maintainers have a good back-porting policy, they'd also put out a new 1.0.X release so that users of <1.1.0 can upgrade and get the fix without also getting the new function in 1.1.0. This is something that Apple sometimes does for security updates on macOS: they'll release a new patch version on all supported versions.

epage 5y ago

I feel minor vs patch is useful for communicating and for the psychological effect. Most people won't care about adding a stray function for one person. Major new functionality is different. Yes, this mixes "sentimental versioning" in with semver. People tend to rate limit their major and minor versions, waiting until they get enough changes to "justify" it. While this can have a negative effect for small additions, I think its good to rate limit deprecations which are important for minimizing the impact of breaking changes.