Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

pod oudated reports unstable versions and versions with a higher platform dependency #1263

Closed
johanneswuerbach opened this Issue · 6 comments

3 participants

@johanneswuerbach

The pod outdated command currently reports beta versions and pods with a higher platform dependency.

platform :ios, '5.0'
pod 'AFNetworking', '~> 1.2.0'
The following updates are available:
- AFNetworking 1.2.1 -> 2.0.0-RC1

I think the AFNetworking update should list 1.3.1 by default as this is the latest stable version and the latest version matching the platform requirement. (so I can really update)

Bundler hides beta versions, if you are not using a lower beta version, I think pod should do that, too.

What do you think?

@fabiopelosin
Owner

I think that pod outdated should show pre-release Pods and those that would require a bump of the deployment target. In the end the purpose of the command is to inform the user that an update exists. For example I might be starting a project which I expect to complete in a couple of months, so it might make sense to adopt a pre-release as soon as it is available as I expect the stable one to be ready before shipping the app. In other words, showing all the Pods leave the choice in the hands of the user.

If the same behavior is happening in pod update it might be a different story. In any case I'm not sure as keeping the bundler approach with pre-releases might be the best fit for an Obj-C package manager. Ruby is not statically typed so pre-release versions tend to be much more unstable than those of a language with a strong type like Obj-C. //c @alloy.

@johanneswuerbach

I wouldn't sign the ruby & obj-c comparison, but what is the intention of a beta release?

In my mind you are releasing a beta version, if you want others to test your lib, but you don't want this code to be used in production as you think it isn't ready yet (otherwise you release a final).
bundler provides an additional switch --pre for displaying beta updates, which I think is a good way to go. Allow interested developers to test the beta and don't get spammed by unadventurous developers complaining about api changes between beta versions or the amount of bugs.

The should also be a switch for the platform target as some of our apps are fixed to a specific platform (OS X 10.6) and we can't simply check for new versions working on this platform as they are "hidden" behind the latest version.

E.g. AFNetworking 2.0 requires iOS 7 / 10.9, which can't be the target platform for many existing apps in the next months. So, checking for new for updates for AFNetworking is quite useless today and I wouldn't see that there was a 1.3 released, which stills supports iOS 5/6, and I wouldn't receive the update with "~> 1.2.0".

@fabiopelosin
Owner

In my mind you are releasing a beta version, if you want others to test your lib, but you don't want this code to be used in production as you think it isn't ready yet (otherwise you release a final).

I might release a beta even though I think that the code is ready. For example the functionality offered might be complex and the best validation solution might be to release it in the field in order to see if somebody encounters a regression.

The should also be a switch for the platform target as some of our apps are fixed to a specific platform (OS X 10.6) and we can't simply check for new versions working on this platform as they are "hidden" behind the latest version.

Point taken.

What about showing the last stable version compatible with the deployment target along the last known version (if different)?

@johanneswuerbach

Sounds good :)

@adamyanalunas adamyanalunas referenced this issue in steipete/AFDownloadRequestOperation
Merged

Prevent pulling in AFNetworking 2.0 #39

@CocoaPodsBot
Collaborator

Issue has been confirmed by @neonichu

@fabiopelosin fabiopelosin referenced this issue
Closed

Refine pod outdated #2470

0 of 2 tasks complete
@fabiopelosin

Moved to #2470

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.