SAFE-Stack / SAFE-template

dotnet CLI template for SAFE project
MIT License
282 stars 87 forks source link

Specify major version in paket.dependencies #487

Closed olivercoad closed 1 year ago

olivercoad commented 2 years ago

So that things don't break when dependencies make breaking changes and bump the major version number.

Using ~> operator, as discussed in #180

theimowski commented 2 years ago

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.

theprash commented 2 years ago

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".

theprash commented 1 year ago

We have a workaround and no clear path forward here so I'll close the issue.

mattgallagher92 commented 1 year ago

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.

olivercoad commented 1 year ago

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.

mattgallagher92 commented 1 year ago

Merged PR.