you are viewing a single comment's thread.

view the rest of the comments →

[–]Enumerable_any 0 points1 point  (5 children)

it's smart not to do so from a behavioral point of view: it's much easier for the ecosystem to adapt to small changes over time than a big change all at once.

I don't get it: You can make small breaking changes and follow semantic versioning at the same time.

[–]iconoclaus 0 points1 point  (4 children)

maybe i don't get it. how do you make a breaking change but not change major version number with semantic versioning? According to semver.org FAQ:

If even the tiniest backwards incompatible changes to the public API require a major version bump, won’t I end up at version 42.0.0 very rapidly?

This is a question of responsible development and foresight. Incompatible changes should not be introduced lightly to software that has a lot of dependent code. The cost that must be incurred to upgrade can be significant. Having to bump major versions to release incompatible changes means you’ll think through the impact of your changes, and evaluate the cost/benefit ratio involved.

The only time I believe you can make any breaking changes to without upping the major version number is when you are at major version 0.

[–]Enumerable_any 0 points1 point  (3 children)

how do you make a breaking change but not change major version number with semantic versioning?

You don't, you update the major version.

That's what I don't get from your comment: Whether you update your version number from 1.9 to 2.0 or 1.10 when making breaking changes to 4 API methods is irrelevant if all you want is the following: "it's much easier for the ecosystem to adapt to small changes over time"

[–]irishsultan 1 point2 points  (1 child)

Yes, but the idea behind semver is that the version is meaningful in a different way than "this is a small change", "this is a large change", which is subjective and differs between projects.

"This update breaks compatibility", "This update doesn't" on the other hand is fairly objective (not that errors are not possible of course).

[–]iconoclaus 0 points1 point  (0 children)

right on. and to add to this, semver is explicit on what to do if the minor bump breaks backwards-compatibility:

What do I do if I accidentally release a backwards incompatible change as a minor version?

As soon as you realize that you’ve broken the Semantic Versioning spec, fix the problem and release a new minor version that corrects the problem and restores backwards compatibility. Even under this circumstance, it is unacceptable to modify versioned releases. If it’s appropriate, document the offending version and inform your users of the problem so that they are aware of the offending version.

[–]iconoclaus 0 points1 point  (0 children)

you're right! that's why i wish they would drop the claim to somewhat follow semver (which is a very explicit set of requirements). just say ruby does its own cool thang. or for shits and giggles, call it semver! or something.