I am pretty sure this is exactly the problem semantic versioning is trying to solve. You only pin to the major version, which is supposed to ensure no breaking change occurs.
Interesting. Can you explain why you're doing one-off fixes instead of creating a general release with the fix that everyone can use? This seems like a bit of a complicated edge case that most people don't need a solution for. Semantic Versioning is very simple and has no intention of solving every possible versioning problem.
It used to work that way, though; software in the 90s and early 2000s did have sane semantic versioning, updates were backported to earlier major versions, and revision updates generally didn't break anything in production.
I bet semantic versioning is mostly championed by older veterans who have worked in maintenance or systems administration roles and are trying to get the industry to return to a versioning system that made sense once upon a time.
For my part ... while I'd dearly love to see semantic versioning come back, along with a few other good habits from a long time ago, I've given up on that and now just accept that updates will break things sometimes and there's always something to update and so something will be broken most of the time and that's just how it is so charge accordingly.
You're always going to have trouble if you try to "enforce" semantic versioning, because it's a social commitment by project maintainers, not a theorem that can't ever possibly exist about "breaking changes" (which has a fuzzy, social definition).
The best option for projects is probably to loudly declare that you are not using semantic versioning, and then use it anyway, on the good-faith basis that is the only actually possible way to use it. Declaring that you don't use it will head off trouble from people who expect it to be an impossible magic constraint, while using it will help people make sense of your version numbers.
Sure, but semantic versioning really is the wrong kind of versioning to use for a language. The major version should represent major language changes, not whether its a breaking change or not, semantic versioning isn't somehow magically a "good" way to version. It's useful for libraries / dependencies where you are dealing with many different libraries and just want to know you can upgrade without having to deal with breaking changes. For a language? Silliness. Your version is not really telling you the main things you care about.
It's much much more useful to the users to say, 2.0 introduced generics, it's distinct. If it's like other languages, generics changes the code people generate a lot, libraries start looking significantly different. It's very distinct, and if that is simply in version 1.18.0 or whatever, that is super bad usability from a language perspective.
Something I've never quite understood about semantic versioning. Sometimes fixing a bug is a breaking change, especially if someone is relying on that behavior to be bugged. How does one make the distinction?
Actually, following the semantic versioning approach there is no need to use anything but the major versions, because only them should make backward-incompatible changes.
Yeah. Painful. Thats the kind of thing semantic versioning aims to solve: within a major release, all minor and patch releases must maintain backwards compatibility. Patch releases may not change the API at all; minor releases may add to it but not remove things[1]. Major releases may drop backwards compatibility by removing or modifying API items. Seems like a reasonable system to me and would avoid the problem you mentioned.
[1] I guess it can deprecate things, as long as they are still available for use.
That was very much not the default expectation; expecting that things wouldn't break would mean you could update with no oversight, and I don't know a time when that was ever expected.
Things broke all the time, the default expectation was that _something_ would need work, it was just a matter of how much. Semantic Versioning just gives us a framework to (try) to know in advance how much work it would be.
Miatakes happen but as an end user of a library I prefer having semantic versioning giving me a hint on where it is likely there is an API breakage and where there is unlikely to be one. I still use lock files, read release notes and test but knowing where things are likely to break saves me time.
Semantic versioning is a curse. It makes perfect logical sense until you are a few iterations in and quickly run into dependency hell as shown in the diagrams in the article.
My solution to this isn't "never update anything", but rather "never version anything". People can choose to stick to the bits they originally got, which is perfectly fine, or they can switch to the current "live" one. As a developer I'm only ever building and maintaining the latest source.
reply