If i define a version in pod file:
Example (AFNetworking 1.3.3 is installed)
pod 'AFNetworking', '1.3.3', '< 2.0'
pod 'AFNetworking', '< 2.0'
pod outdated shows that there is a 2.0.2 version available.
I think it should only show that message if a new version below 2.0 is available, or did i miss something?
(Copy of https://github.com/CocoaPods/Specs/issues/5450)
I think that the goal of this command is to have an overview of all the outdated pods that you're currently using.
So if you are using pod 'AFNetworking', '< 2.0' then it makes sense for the command to point out that there is a 2.0.2 version.
pod 'AFNetworking', '< 2.0'
It would be good however that pod outdated would take into account your platform setting as don't consider your pod outdated if you cannot anyway (#1263) update it for your current platform (which is at the end what you tried to achieve as 2.x is iOS 6+ only).
If someone wants to refactor the outdated function there are a couple of related issues.
I don't agree with the first point. If you define your version should be < 2.0 you make a decision for using only 1.x releases. So you don't need to informed that there is a 2.x release.
And: Actually you don't get informed if a new 1.x release is available, because the 2.x releases have higher numbers.
I agree to part 2, with one exception: not only supporting old iOS version could be a reason, also a major api change in the 2.0 release and the refactoring could be an issue.
An analogy would be with iOS devices. You may prefer/use < iOS 7 for any reason but if you ask anyone it would be an outdated version (point 1).
Unless off course you have an iPhone 3G. In this case you're not outdated with iOS 6 as there's no way to use iOS 7 there (point 2).
If refactoring is an issue to update but is technically possible, then your pod is still outdated and potentially missing bug/security fixes.
Issue has been confirmed by @segiddins
We might be able to introduce a CLI option for this. E.g. pod outdated --ignore-version-requirements and pod outdated --respect-version-requirements. pod outdated would then default to the former.
pod outdated --ignore-version-requirements
pod outdated --respect-version-requirements
I’m still on the fence, though.
As this just came up, I'm with the defaults to using podspec for showing outdated in what I feel is important, and optionally having --ignore-version-requirements as an argument for showing the global what's new.
I vote for no option: The command should show the updates that are within your version requirements and those those that are outside them.
An option might be useful to limit only the scope... so for an example a script might fail the CI if there is an update within the version requirements.
Moved to #2470