The main problem with the current Semantic Versioning doc is that by not mentioning this issue it encourages developers to break backward compatibility, giving them impression that increased major version number will protect the clients from trouble.
Instead, breaking changes should be discouraged - in majority of cases it is trivial to keep backward compatibility. (For example, instead of altering function behavior, keep the old function as it is and introduce a new function).
If breaking change is still needed, the developer has to make sure the new version of the library can be loaded simultaneously with the old version. In many languages that will require giving the library new identifier, using new namespace / package in the library source code.
--------
In the current form the document is an invitation to break backwards compatibility any time, under a false promise that changing major version number solves all dependency hell issues
--------
Once again, the point of this ticket is to:
1. Remove the false promise that SemVer solves dependency hell by simply increasing major version.
2. Discourage unnecessary compatibility breakages, when it's trivial to maintain compatibility.
3. Several sentences of advice for the cases when comparability breakage is really needed.
This isn't a problem with semver, it's a problem with developer attitudes and behavior. Arguably semver does nothing to affect this either way, and adding "several sentences" will do exactly nothing to change it.
Encourages to break compatibility? I'd say it does the opposite. It forces developers to fess up that they broke compatibility. I avoid any lib that has rapidly increasing major versions. Tells me the maintainer is wishy washy and gives 0 hoots about stability.
You arguments here and in another comment support my view actually, although shaped as if they were opposing it.
Tells me the maintainer is wishy washy and gives 0 hoots about stability.
Maybe the maintainer have read the famous engineering best practice manifesto SemVer, and rests assured that increased major version number allows him to introduce incompatible changes safely?
Comments
This is answered multiple times in the ticket.
--------
--------
1. Remove the false promise that SemVer solves dependency hell by simply increasing major version.
2. Discourage unnecessary compatibility breakages, when it's trivial to maintain compatibility.
3. Several sentences of advice for the cases when comparability breakage is really needed.
You can't standardize "unnecessary"
This isn't a problem with semver, it's a problem with developer attitudes and behavior. Arguably semver does nothing to affect this either way, and adding "several sentences" will do exactly nothing to change it.
Please stop trolling. The several sentenses are not suggested to change "it".
Encourages to break compatibility? I'd say it does the opposite. It forces developers to fess up that they broke compatibility. I avoid any lib that has rapidly increasing major versions. Tells me the maintainer is wishy washy and gives 0 hoots about stability.
You arguments here and in another comment support my view actually, although shaped as if they were opposing it.
Maybe the maintainer have read the famous engineering best practice manifesto SemVer, and rests assured that increased major version number allows him to introduce incompatible changes safely?
Well, it is safe Just not good for users.