4 ms·

The main problem remains not solved: https://github.com/semver/semver/issues/771 https://github.com/semver/semver/issues/771

tracerbulletx 3y ago
What does that have to do with the semantic versioning scheme?
Aeolun 3y ago
I agree with the first comment on that issue that that is not an issue with semver, and arguably not even an issue with the package manager. It protects you against yourself, and it forces maintainers to keep their libraries up to date less all their users disappear for inability to upgrade.
bastawhiz 3y ago
This remains a problem regardless of whether a library uses semantic versioning or not. How would the semantics of version numbers affect whether multiple copies of a library are included in a project?
- avodonosov 3y ago
  This is answered multiple times in the ticket. > 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.
  - bastawhiz 3y ago
    > Discourage unnecessary compatibility breakages You can't standardize "unnecessary" > 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.
    - avodonosov 3y ago
      Please stop trolling. The several sentenses are not suggested to change "it".
  - 8n4vidtmkvmk 3y ago
    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.
    - avodonosov 3y ago
      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?
      - 8n4vidtmkvmk 3y ago
        Well, it is safe Just not good for users.

tracerbulletx 3y ago

What does that have to do with the semantic versioning scheme?

Aeolun 3y ago

I agree with the first comment on that issue that that is not an issue with semver, and arguably not even an issue with the package manager. It protects you against yourself, and it forces maintainers to keep their libraries up to date less all their users disappear for inability to upgrade.

bastawhiz 3y ago

This remains a problem regardless of whether a library uses semantic versioning or not. How would the semantics of version numbers affect whether multiple copies of a library are included in a project?

avodonosov 3y ago
This is answered multiple times in the ticket. > 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.
- bastawhiz 3y ago
  > Discourage unnecessary compatibility breakages You can't standardize "unnecessary" > 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.
  - avodonosov 3y ago
    Please stop trolling. The several sentenses are not suggested to change "it".
- 8n4vidtmkvmk 3y ago
  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.
  - avodonosov 3y ago
    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?
    - 8n4vidtmkvmk 3y ago
      Well, it is safe Just not good for users.