SAFE-template
SAFE-template copied to clipboard
SAFE-Stack
Specify major version in paket.dependencies
So that things don't break when dependencies make breaking changes and bump the major version number.
Using ~> operator, as discussed in #180
I'm not convinced we should do this - yes on one hand you might get breaking changes, but on the other hand if you make ~> a default, one would need to manually remove it to get a new major version.
One option is to use the --keep-major option on Paket's update, add and install commands. It makes Paket "only allow updates that preserve the major version".
We have a workaround and no clear path forward here so I'll close the issue.
Reopening based on discussion in #553.
You're right @theimowski that this change would require removing the restrictions to upgrade the major version of a package. However, I would contend that that's a good thing: it's often the case that changing the major version of a dependency will break an application, so it should be a conscious decision by a developer to upgrade a package's major version, rather than one that the tooling makes on a developer's behalf.
My thought is that we should provide more stability during Paket changes. The current approach leaves Paket free to make changes such as the one underlying #553. I've also faced problems where adding a new dependency via Paket has upgraded the version of an existing dependency, resulting in runtime errors. (The particular example was adding Fable.FormValidation, causing an upgrade to Fable.React, which then broke other packages dependent on Fable.React.)
In my opinion, the suggested approach strikes the right balance between stability and upgradability: it's usually safe to assume that staying within the same major version will not break things, and it's still possible to get minor enhancements and bugfixes.
Thanks all for the discussion on this over in #553 and thanks @Tom-Sloboda for making the PR (#559). I agree that it's a good thing that you'd have to manually change it to get a new major version, because if a library is explicitly saying it has a breaking change by incrementing the major version, then I usually want to know about it and take the time to look at the changelog to find out what (if any) other changes I need to make while updating it.