Information about new major version release of the SPM dependency

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

3 Likes

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.

3 Likes

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.

1 Like

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.

1 Like

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.

1 Like

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.

5 Likes

OK, so what we have to do to convince the team responsible for SPM to put this idea on the TODO list?

1 Like
Terms of Service

Privacy Policy

Cookie Policy