Skip to content

Commit

Permalink
[Update] CardIO (3.4.1)
Browse files Browse the repository at this point in the history
  • Loading branch information
@kylefleming
kylefleming committed Dec 8, 2013
1 parent 0d74b12 commit a318bf5
Showing 1 changed file with 23 additions and 0 deletions.
23 changes: 23 additions & 0 deletions CardIO/3.4.1/CardIO.podspec
View file
@@ -0,0 +1,23 @@
Pod::Spec.new do |s|
s.name = 'CardIO'
s.version = '3.4.1'
s.homepage = 'https://www.card.io'
s.summary = 'An easy to use credit card scanning tool.'
s.author = { 'CardIO' => 'support@paypal.com' }
s.source = { :http => "https://github.com/card-io/card.io-iOS-SDK/releases/download/v#{s.version}/card.io_ios_sdk_#{s.version}.zip", :flatten => true }
s.source_files = 'CardIO/*.h'
s.preserve_paths = 'CardIO/*.a'
s.xcconfig = { 'LIBRARY_SEARCH_PATHS' => '"$(PODS_ROOT)/CardIO/CardIO"' }
s.frameworks = 'AVFoundation','AudioToolbox','CoreMedia','CoreVideo','MobileCoreServices','OpenGLES','QuartzCore','Security','UIKit'
s.libraries = 'CardIO', 'c++'
s.requires_arc = true
s.platform = :ios, '5.0'
s.license = {
:type => 'Commercial',
:text => <<-LICENSE
All text and design is copyright © 2012 Paypal.
All rights reserved.
LICENSE
}
end

15 comments on commit a318bf5

@keith
Copy link
Member

@keith keith commented on a318bf5 Dec 9, 2013

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Every single one of these commits has broken the master build for not specifying a tag. You should NEVER be pushing this directly with git, with push access you should be using pod push. You should also NEVER submit a spec without running pod spec lint which none of these would have passed. Thank you for fixing these but please never do this again.

@keith
Copy link
Member

@keith keith commented on a318bf5 Dec 9, 2013

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like some of these may still be broken. Please fix them ASAP or I will remove them.

@kylefleming
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Keithbsmiley Thank you for your concern. I have run pod spec lint on all versions and have tested each one individually to make sure they can be installed and compiled in a sample app.

Versions 3.4.0 and 3.4.1 were done with pod push and have no problems. Versions 3.2.x and 3.3.x were done with pod push --allow-warnings. This is because 3.2.x and 3.3.x don't have tags in the repo at all, so even though the previous podspec referenced a tag, those tags didn't exist and you couldn't actually pod install the library for any of those versions, hence I switched it to referencing a commit hash.

My impression of the matter is that using a commit hash is issued as a warning and not an error because sometimes it's the only way, such as in this case. If the policy for CocoaPods has changed such that versions referencing commit hashes are disallowed, then yes we'll have to completely remove these versions for CocoaPods/Specs, but I don't think this is advisable since it prevents users from actually installing these versions of the library through cocoapods, until the owner of the repo adds tags for those versions.

@kylefleming
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm looking into the whitelist now, as I think that is the solution here.

@keith
Copy link
Member

@keith keith commented on a318bf5 Dec 9, 2013

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently I rarely make exceptions allowing any non-tagged or unversioned specs into the repo. If that version a version cannot be used because of it we need to attempt to contact the repo maintainer to tag what we want.

@kylefleming
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Problem resolved. Thanks for pointing out the issue, @Keithbsmiley

@kylefleming
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I'll petition the owner to add tags to their repo. I'm not confident they will oblige since they have obliterated their repo in a weird way to remove all previous versions, even though it still exists in the repo history. Let's see what they say.

@keith
Copy link
Member

@keith keith commented on a318bf5 Dec 9, 2013

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair enough. In the mean time I've removed removed the broken specs dfa797a and the addition to the whitelist ada71c0

This is not the purpose for the whitelist. It only exists for specs that are in essence grandfathered in to rules that have developed over time. Not to add new exceptions to the repo. If the owner of the repo adds tags to it these specs can be readded.

@kylefleming
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok I understand.

My logic in adding the whitelist vs removing the podspecs is that these library versions are already in many production apps (ours included, which is what sent me down this whole mess). My best guess at what happened is that the owner of the repo has removed the tags for these versions, which broke the podspecs, hence I couldn't pod install my app anymore. Switching over to using the commit hash was a bandaid to allow existing apps to still run fine, as opposed to the case of adding a new version of a library entirely which no one is yet relying on.

Previously, we were using 3.3.0 of CardIO which was suddenly broken and the only reason I can now continue my work is because we upgraded to 3.4.0 which now works properly after tweaking the podspec. I don't think it's fair to force all users of this library to upgrade to the latest version while we contact the owner. Although I assume the owner wishes everyone to upgrade, which is why they are trying so hard to prevent you from accessing old versions (by resetting the git history and removing tags). So while yes upgrading is the ideal course of action, users of the library shouldn't be required to stop all work until they upgrade their CardIO library.

I suggest we keep 3.2.0, 3.2.2, 3.2.3, and 3.3.0 since those are the versions that were in cocoapods before today. They will need to reference the commit hash though and also be whitelisted. Versions 3.2.1 and 3.2.4 were added today and can safely stay absent.

Meanwhile, no matter how we proceed, we will still wait for the owner to add version tags.

@keith
Copy link
Member

@keith keith commented on a318bf5 Dec 9, 2013

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ugh. This is more complicated then. For now I'd recommend making a second repo in ~/.cocoapods/repos and add these specs to that locally. Lets try and get @orta and some other folks to weigh in on this since it's a little unusual for the repo maintainer to delete those tags...

@alloy
Copy link
Member

@alloy alloy commented on a318bf5 Dec 9, 2013

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Regardless of what a vendor decides to do, I completely agree with @Keithbsmiley. They are clearly (trying?) making it hard for their users to use it, regardless of wether or not CocoaPods is being used. Please let us know when/if you have created a ticket with them to complain about this.

@fabiopelosin
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I consider as well this behavior inconvenient for developers which are not allowed to perform the update when is most convenient for them.

I think that we should decide a policy about Pods which actively try to break the guarantees of the master repo. One possibility could be to ban them from the specs repo (they would still be free to support CocoaPods as an installation mean but they would need to maintain their own repo or distribute the podspec directly) at least until CocoaPods becomes a package manage system (not happening before 1.0 if it will ever happen).

@orta
Copy link
Member

@orta orta commented on a318bf5 Dec 9, 2013

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From the looks of things it'd be a smart move for @alloy or @irrationalfab to send them an email and see if we can figure their future plans rather than trying to divine it out via the tea-leaves.

@kylefleming
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

An issue has been created on the CardIO repo. card-io/card.io-iOS-SDK#24

@kylefleming
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CardIO has agreed to deprecate and maintain access to old library versions for 6 months, except when security concerns are present.

As a side note, I wonder if there's a way to better inform the user of what they must do in certain cases. In the case of a newer version becoming available, does it make sense to add a warning when they pod install that one of their libraries is deprecated and should be updated since it will be removed in the near future? (This could be handled with a sort of "notice" config in the podspecs of the old versions) I understand also that users should generally update their libraries periodically and that 6 months is likely long enough that most users will have upgraded within that time regardless.

In the case that a version is suddenly missing and pod install fails, what indication could be given to the user that they should upgrade the CardIO pod to a newer version? Would keeping the podspec for that version in the master repo but flagging it as "uninstallable" work?

I'm just throwing ideas out there, none of which seem likely to be implemented. My guess is that the old versions will be removed from cocoapods once the distribution method is removed and that users will just have to figure it out on their own.

Please sign in to comment.