Hi, when I use Update to latest package version it only updates to next major version. This is great but I would like to also know that the dependency has a new major release and I can manually update the number in Xcode. Currently I have to check all ma 30+ dependencies by copy-pasting github url to browser, which is not fun at all. Would it be possible to notify or inform user that dependency in the Navigator has a major version bump?
Thanks
Update to the latest package version uses the version rules set for your dependencies so you should be able to also update major releases if you set your SPM dependencies version rules to "Range" and specify an arbitrary high number as a limit.
If the repository uses a release branch, you could also specify that branch in the SPM settings.
Generally speaking Major updates often mean breaking changes so I don't think its a good idea to update automatically, especially if you have a lot of dependencies.
Sure, but often bumps in major version number means cleaning up incompatible API surfaces, following migration guides, replacing deprecated functions. Sometimes even massive rewrites of parts of your application.
It makes sense to use the "up to next major" strategy for most dependencies.
But it would also be nice to get notified that there is a newer version available, and links to it, and you could make informed decisions, on a case-by-case basis, whether to stay at the current version, or bump it up. Maybe put an issue in your backlog to investigate new features, and cost-of-migration. An option to silence the warning until next major version, would be nice.
Now, we often have to choose to either use your strategy of using an arbitrarily high limit, and manually reverting single packages whenever it leads to a non-building project. Or to silently miss nice-to-have major upgrades, even when they are pretty easy to just plug in.
I support better support for dealing with major version updates.
I have to agree with you. I slightly misunderstood @elSwifto and thought it was about the ability to automatically update not some kind of update notification.
Maybe a badge for updates in the Xcode project navigator would be nice.
Note that some caution needs to be done with user interface design around this kind of functionality. It's probably more straightforward to consider the text user interface of swift package update here, for now.
Consider the case where you have a diamond dependency, where both you and one of your dependent packages depend on the same version of a third package. If that third package provides a new major release, should you be warned to try to update? What should it say?
Concretely, the issue here is that the other package constrains your movement. At the version currently resolved, you could not update the major dependency. In principle you could update the other package and see if that helps, but the only way to know is to find out.
I think the question that you need SwiftPM to answer is: "Package A has a new major version available, and if you raise your dependency spec and re-resolve your packages you can get access to it.". Of course, even that's not sufficient: maybe you have to raise the dependency spec for multiple packages! At a certain point you're just asking SwiftPM whether there is any hypothetical dependency spec that will bring in the newer major version, and this rapidly becomes computationally expensive.
It would be sufficient if I as user can see if there is a newer version available which is not covered by my version rules. This could be something like just displaying the newest available package version somewhere next to the packages list, if there is one available.
Updating these rules would not bring any resolving issues if the lower limit is not changed, right?
The issue is that the warning may not be actionable: there may be a new version available that your dependencies prevent you from updating to.
It would always be actionable if the check is run against the configured versions (in Package.swift or Xcode projects) and not against the actual resolved package.
No, I don't think that's true. Consider the following dependency tree, where I am working on MyPackage:
MyPackage, depends on Package A (from: "1.0.0") and Package B (from: "1.0.0")
Package A, depends on Package B (from: "1.0.0")
Imagine that we have the following available versions of each package:
Package A: v1.0.0
Package B: v1.0.0
In this instance, we would have a buildable tree. We'd resolve Package A at v1.0.0 and Package B at v1.0.0.
Now, suppose that Package B releases a v2.0.0. Package B is directly depended upon by me. Package A has not released a new version, and so only has the v1.0.0 release. Should I get a warning here?
While I could raise my own requirement on Package B, to do risks producing an unsatisfiable tree. If I simply do from: "2.0.0" then I will have unsatisfiable dependences: A requires 1.0.0<2.0.0, and MyPackage requires 2.0.0<3.0.0. The only way I could get this to work is to express my own dependency on B as being 1.0.0<3.0.0, which is unlikely to be acceptable.
Yes, that would be great if possible. It would help a lot for all users I think
I understand these concerns and yes an extended version range is often not acceptable but in theory it could be used to "silence" any update notifications.
The same problems would occur if I manually update a package or add a new dependency. I only see that my dependency requirements can't be satisfied after it was updated or added.
And probably the majority of projects doesn't have that many dependencies which depend on each other and that edge case shouldn't be seen too often.
Just because in some (rare) cases a package cannot be updated should not be a reason to never inform the user about any update. After all, all users should be aware that major updates are not always possible without changing code or dependency requirements.
In the end the Package Manager cannot predict what a user wants, taking your example, maybe updating Package B to v2.0.0 enables the user to completely get rid of the direct Package A dependency.
Silencing update notifications by producing projects that can't build in some cases is a bad solution.
Yes, but not having a dependency does not produce a warning. My specific concern is with having a build configuration that produces a warning, but where no meaningful action can be taken to resolve it and it cannot be suppressed.
I think this is worthy of a [citation needed]. At least in the Swift on Server space, SwiftNIO is explicitly depended upon by a wide range of libraries, meaning that most server-side applications have multiple paths by which they depend on SwiftNIO.
I agree with all of this. What I'm saying is that this should likely not be a default mode. I'm all for the Package Manager being able to tell you that there is a new package version that your current dependency tree does not allow you to adopt if you ask it to. What I don't want is on-by-default non-actionable warnings: they just end up as build noise and get ignored.
OK, so what we have to do to convince the team responsible for SPM to put this idea on the TODO list?
We've made spm-check-updates to help us keep all dependencies up-to-date
==> Downloading https://github.com/gorillatech/spm-check-updates/archive/refs/tags/0.1.1.zip
==> Downloading from https://codeload.github.com/gorillatech/spm-check-updates/zip/refs/tags/0.1.1
##O#-#
Error: spm-check-updates: SHA256 mismatch
Expected: e070c88bc52178d803f46604d9c28ddaf6f89032c6037a5528c0976b9d8e8321
Actual: 37d1905e1380239d82cc64ef3925862516b52b3c39f2a773e2406fc502103f4f
File: /Users/sveinhal/Library/Caches/Homebrew/downloads/c09d02309207fbddf720cbef12a2df0ce0167f84f08a2b4a8497b327c9e7370a--spm-check-updates-0.1.1.zip
To retry an incomplete download, remove the file above.
Thanks for reporting this... It should be fixed now.
I know the struggle. Xcode's update feature doesn't differentiate between major, minor, or patch updates, and that can be frustrating.
I've started using an app called Packlyft that makes this whole process so much easier. It keeps my Swift packages up to date, including major updates, and it works perfectly with both .xcodeproj and Package.swift projects. The in-app browser is a great feature too—it lets me quickly check release notes without leaving the app. It’s saved me a lot of time and effort.
If you're running into the same issue, it might be worth a look.
You can check it out here: Packlyft on the App Store.