3 ms·

The SemVer summary states: Major: for incompatible API changes Minor: for backwards-compatible new functionality Patch: for bug fixes A few sparse thoughts:

by Udik 8y ago

The SemVer summary states: Major: for incompatible API changes Minor: for backwards-compatible new functionality Patch: for bug fixes A few sparse thoughts: The definition seems to imply that version 1.1.0 can have twice the features of v.4.0.0, which in turn might have exactly the same features as version 1.0.0, just backwards incompatible. APIs that strive for backward compatibility never get a "major" release? Has Windows ever had a "major" release? If anybody was relying on a bug to be present, does that qualify the patch as major? And how do you know it in advance? I can understand the usefulness of SemVer; what I don't understand is why it should replace instead of integrate the usual release numbers. Just because they both are described by the same English word?

nybble41 8y ago
> The definition seems to imply that version 1.1.0 can have twice the features of v.4.0.0, which in turn might have exactly the same features as version 1.0.0, just backwards incompatible. That's possible. Feature regressions sometimes happen when software is redesigned, or obsolete features may have been deprecated and removed. Either case would be a breaking change leading to a major version bump. > APIs that strive for backward compatibility never get a "major" release? That's right. Why would you announce that you're introducing breaking API changes when you're actually maintaining backward compatibility? That just makes headaches for you users, and for the sake of what? Marketing? > If anybody was relying on a bug to be present, does that qualify the patch as major? If fixing the bug changed any official, public, documented APIs in a breaking way, then yes—or if the documentation was inadequate such that the implementation essentially was the official APIs. If it only affects users who were not following the APIs, that's more of a grey area. I'd say that's their problem, not the library authors'; if you use a library in interesting and novel ways, contrary to the directions, and it breaks as a result, you get to keep both pieces. That isn't a bug in the library and doesn't reflect on the semantic versioning. > And how do you know it in advance? Sometimes you don't. In that case the unexpected API breakage is a bug just like any other, and you'd need to retract the minor/patch release and either bump the major version or fix the break in the API.

by Udik 8y ago

nybble41 8y ago

> The definition seems to imply that version 1.1.0 can have twice the features of v.4.0.0, which in turn might have exactly the same features as version 1.0.0, just backwards incompatible. That's possible. Feature regressions sometimes happen when software is redesigned, or obsolete features may have been deprecated and removed. Either case would be a breaking change leading to a major version bump. > APIs that strive for backward compatibility never get a "major" release? That's right. Why would you announce that you're introducing breaking API changes when you're actually maintaining backward compatibility? That just makes headaches for you users, and for the sake of what? Marketing? > If anybody was relying on a bug to be present, does that qualify the patch as major? If fixing the bug changed any official, public, documented APIs in a breaking way, then yes—or if the documentation was inadequate such that the implementation essentially was the official APIs. If it only affects users who were not following the APIs, that's more of a grey area. I'd say that's their problem, not the library authors'; if you use a library in interesting and novel ways, contrary to the directions, and it breaks as a result, you get to keep both pieces. That isn't a bug in the library and doesn't reflect on the semantic versioning. > And how do you know it in advance? Sometimes you don't. In that case the unexpected API breakage is a bug just like any other, and you'd need to retract the minor/patch release and either bump the major version or fix the break in the API.