Closed vokal-isaac closed 9 years ago
Looks good to me pending travis
So great
Travis likes it.
Also, once this is merged, it will need to be tagged 1.4.0
and pod trunk push
ed.
I'll get it done
@vokal-isaac Sad trombone - when I ran pod spec lint
it looks like BRLOptionParser pulled their 0.3.1 tag:
[!] /Applications/Xcode.app/Contents/Developer/usr/bin/git clone https://github.com/barrelage/BRLOptionParser.git /private/var/folders/2w/_5g70ypd601056s6t9pn73q80000gq/T/CocoaPods/Lint/Pods/BRLOptionParser --single-branch --depth 1 --branch v0.3.1
Cloning into '/private/var/folders/2w/_5g70ypd601056s6t9pn73q80000gq/T/CocoaPods/Lint/Pods/BRLOptionParser'...
warning: Could not find remote branch v0.3.1 to clone.
fatal: Remote branch v0.3.1 not found in upstream origin
Unexpected end of command stream
Hmmm... where's it getting that from? I don't see it in the podspec (the Podfile has pod 'BRLOptionParser', :git => 'https://github.com/vokal-isaac/BRLOptionParser.git' #'~> 0.3.1'
—I think 0.3.1
was what I was anticipating would contain the fix that I made in my fork or something similar and while a different fix from mine was implemented, the podspec/tag for BRLOptionParser
hasn't been updated).
Actually, it may not matter—it may just be one of those times when using the --allow-warnings
flag is the thing to do.
if you ~> 0.3.1
, I believe that means it's supposed to be at least 0.3.1. If there's no tag, I'd advise just pointing it at a specific commit for now.
Yes, but I don't actually reference 0.3.1 anywhere—there's a commented-out bit about it, but it's actually pointing at my fork, via :git =>
, which precludes using a version.
Oh yeah, wait a second - why does this even give a shit about BRLOptionParser, it's not a part of the podspec. Lemme update cocoapods, I know they sent out a patch relelase.
awesome. No update, but pod spec lint
fails and pod trunk push
works.
¯\_(ツ)_/¯
I think pod spec lint
is overly-sensitive. pod trunk push
also does some linting and it's also overly-sensitive, which is why we've got that note about potentially needing the --allow-warnings
flag in our private podspec repo.
... and use those constants in the image-getting methods. Having these constants generated provides the end-consumer with a non-stringly-typed way to use
+ [UIImage imageNamed:inBundle:compatibleWithTraitCollection:]
if they so choose, to work around #12.@vokal/ios-developers Code review?