I'd like to propose that we implement a mint outdated command, which mirrors the sort of functionality we get out of bundle outdated, gem outdated, pod outdated, and so on by showcasing which dependencies are out of date.
$ pod outdated
Analyzing dependencies
The color indicates what happens when you run `pod update`
<green> - Will be updated to the newest version
<blue> - Will be updated, but not to the newest version because of specified version in Podfile
<red> - Will not be updated because of specified version in Podfile
The following pod updates are available:
- Firebase 6.21.0 -> (unused) (latest version 6.24.0)
- FirebaseAnalytics 6.4.0 -> 6.4.0 (latest version 6.5.0)
- FirebaseCore 6.6.5 -> 6.6.5 (latest version 6.7.0)
- FirebaseCoreDiagnostics 1.2.2 -> 1.2.4 (latest version 1.3.0)
- FirebaseInstallations 1.1.1 -> 1.2.0 (latest version 1.2.0)
- FirebaseInstanceID 4.3.2 -> (unused) (latest version 4.3.4)
- FirebaseRemoteConfig 4.4.9 -> 4.4.10 (latest version 4.4.10)
...
Considerations
How do we handle globally-scoped packages vs. Mintfile-scoped packages?
Any run of mint outdated should include the global packages and local packages in separate groupings. If there are any conflicts, the local packages are shown.
How do we handle pinning to a branch or tag (eg. yonaskolb/Mint@master)?
Anything pinned to a branch or tag should simply show the latest release.
Additional Notes
I'm happy to attempt the work for this, but looking for additional input into the considerations here before I continue. Will add any questions to the topic above.
Additionally, I believe that the CocoaPods implementation is the smoothest. Unfortunately, we don't seem to have a swift outdated command yet we could rely on, otherwise we could just run whatever SPM has. Until that day, it would be nice to implement some simple support for this.
Proposal
I'd like to propose that we implement a
mint outdated
command, which mirrors the sort of functionality we get out ofbundle outdated
,gem outdated
,pod outdated
, and so on by showcasing which dependencies are out of date.Examples
Considerations
How do we handle globally-scoped packages vs. Mintfile-scoped packages?
Any run of
mint outdated
should include the global packages and local packages in separate groupings. If there are any conflicts, the local packages are shown.How do we handle pinning to a branch or tag (eg.
yonaskolb/Mint@master
)?Anything pinned to a branch or tag should simply show the latest release.
Additional Notes
I'm happy to attempt the work for this, but looking for additional input into the considerations here before I continue. Will add any questions to the topic above.
Additionally, I believe that the CocoaPods implementation is the smoothest. Unfortunately, we don't seem to have a
swift outdated
command yet we could rely on, otherwise we could just run whatever SPM has. Until that day, it would be nice to implement some simple support for this.