Closed amotl closed 2 years ago
Isn't it better to stumble upon this upgrade, and decide then if we try to accommodate, or limit the versions?
Hi Marios,
thank you for asking.
When a package manager supports pinning package versions using package lock files (like package-lock.json
, yarn.lock
, or poetry.lock
), you are usually describing similar things these days when using caret requirements, like specifying ^1.2.3
, essentially expressing the version constraint >=1.2.3 <2.0.0
, i.e. »allow pulling of minor and patch releases, but don't upgrade to the next major version« in the context of SemVer versioning.
On all projects I am touching recently, I try to adjust dependency constraints into that direction, even when not able to use the »caret requirements« version specification yet.
Isn't it better to stumble upon this upgrade.
I think it is not a good idea to let users stumble into the upgrade.
With kind regards, Andreas.
Thank you very much for the detailed description @amotl. I was thinking that if the upgrade is pulled in, our nightly run for example will fail, and therefore we will then decide if we fix it or restrict the version dependencies.
I was thinking that if the upgrade is pulled in, our nightly run for example will fail.
It would fail at the same time for all other users and we would not be able to do anything about it, other than guiding them to manually downgrade the package or pin it in their dependencies on their own behalf. The intention of this patch is to prevent that, by taking care about this scenario in advance.
Thx, It's very clear! thought it would just break the nightly "package".
Given that the package did not receive any update since 2019, chances are that the next release may bump to a major version, which might not be compatible.