Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Experimental support for bleeding version for git repos. #392

Closed
wants to merge 3 commits into from
Closed

Experimental support for bleeding version for git repos. #392

wants to merge 3 commits into from
+49 −6

Conversation

fabiopelosin
Copy link
Member

I'm experimenting with the possibility to specify a bleeding version with a hash, like:

platform :ios, '5.1'
pod 'RestKit', :bleeding

With this change set in place we could have 0.0.1 podspec being updated (i.e. add 0.0.2.cp) only they don't work anymore in bleeding mode for unversioned libraries.

Known issues:
  • it creates documentation for the spec with the name of last version (i.e. if you later use the non bleeding might end up being confused).
  • missing specs.
  • needs more robust integration with subspecs and and the preferred dependency.
Sample output:

Notice that RestKit is downloaded from head and marked as [BLEEDING].

$ dpod install --no-update --verbose

Resolving dependencies of: /Users/fabio/Desktop/Lambda News/Podfile

Resolving dependencies for target `default' (iOS 5.1)
  - RestKit [BLEEDING]
    - RestKit/JSON (= 0.10.1)
      - RestKit/Network
        - LibComponentLogging-NSLog (>= 1.0.4)
          - LibComponentLogging-Core (>= 1.1.6)
        - cocoa-oauth
          - NSData+Base64 (~> 1.0)
        - FileMD5Hash
        - SOCKit
      - RestKit/ObjectMapping/JSON
        - JSONKit (>= 1.5pre)
        - ISO8601DateFormatter (>= 0.6)
        - RestKit/Network
      - RestKit/ObjectMapping/CoreData
        - ISO8601DateFormatter (>= 0.6)
        - RestKit/Network
      - RestKit/UI

Installing dependencies

-> Installing FileMD5Hash (0.0.1)
-> Cloning git repo
   $ /usr/local/bin/git rev-list --max-count=1 d00c0c51c6d0955d9daf94c30cfd95a219d4914e
   d00c0c51c6d0955d9daf94c30cfd95a219d4914e
   $ /usr/local/bin/git clone '/Users/fabio/Library/Caches/CocoaPods/Git/ee93d7208a5cd34ce13dcdb4b8dcfdd22612fc30' '/Users/fabio/Desktop/Lambda News/Pods/FileMD5Hash'
   Cloning into '/Users/fabio/Desktop/Lambda News/Pods/FileMD5Hash'...
   done.
   $ /usr/local/bin/git checkout -b activated-pod-commit d00c0c51c6d0955d9daf94c30cfd95a219d4914e
   Switched to a new branch 'activated-pod-commit'
-> Using existing documentation

-> Installing ISO8601DateFormatter (0.6)
    ...

-> Installing RestKit/JSON (0.10.1)[BLEEDING]
-> Cloning git repo
-> Updating cache git repo (/Users/fabio/Library/Caches/CocoaPods/Git/3b4327a38aaa13bb7bccccfa640badc94f770919)
   $ /usr/local/bin/git reset --hard HEAD
   HEAD is now at f11a538 Merge branch 'release/0.10.1'
   $ /usr/local/bin/git clean -d -x -f
   $ /usr/local/bin/git pull
   Already up-to-date.
   $ /usr/local/bin/git clone '/Users/fabio/Library/Caches/CocoaPods/Git/3b4327a38aaa13bb7bccccfa640badc94f770919' '/Users/fabio/Desktop/Lambda News/Pods/RestKit'
   Cloning into '/Users/fabio/Desktop/Lambda News/Pods/RestKit'...
   done.
-> Using existing documentation

-> Installing SOCKit (1.0)
    ...

Generating support files
    ...

@fabiopelosin
Experimental support for bleeding version for git repos.

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode
b08b005
@fabiopelosin
Better support for bleeding mode with subspecs.
d57bb9f
@fabiopelosin
Better support for bleeding mode with subspecs.

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode
a24b4ba
@fabiopelosin fabiopelosin mentioned this pull request Jul 12, 2012
Closed
@travisbot
Copy link

This pull request passes (merged a24b4ba into d4f319b).

@alloy
Copy link
Member

alloy commented Jul 12, 2012

So to be clear, it selects the most recent podspec available, but then only uses the git part (url) of the source? I think it’s better if all downloaders respond to download_latest and call that, instead of changing the source in the Specification.

With this change set in place we could have 0.0.1 podspec being updated (i.e. add 0.0.2.cp) only they don't work anymore in bleeding mode for unversioned libraries.

I’m unclear what you mean by this. That we don’t really need the cp versions anymore?

@alloy
Copy link
Member

alloy commented Jul 12, 2012

Btw, instead of ‘bleeding’ I would prefer ‘head’, or ‘latest’. There might be even better options.

@fabiopelosin
Copy link
Member Author

Yes it uses the latest, as per CocoaPods standard behavior when you don't specify a version.

The why I did this way is to isolate the feature otherwise the local pod (as well the downloaders) would need to know about it. But I was not sure wether is the best way to go. What do you think?

Regarding the cp version I just meant that it would be a lot less needed as usually the pod specs don't need to be updated.

On 12/lug/2012, at 15:16, Eloy Duránreply@reply.github.com wrote:

So to be clear, it selects the most recent podspec available, but then only uses the git part (url) of the source? I think it’s better if all downloaders respond to download_latest and call that, instead of changing the source in the Specification.

With this change set in place we could have 0.0.1 podspec being updated (i.e. add 0.0.2.cp) only they don't work anymore in bleeding mode for unversioned libraries.

I’m unclear what you mean by this. That we don’t really need the cp versions anymore?

Reply to this email directly or view it on GitHub:
#392 (comment)

@alloy
Copy link
Member

alloy commented Jul 12, 2012

The why I did this way is to isolate the feature otherwise the local pod (as well the downloaders) would need to know about it. But I was not sure wether is the best way to go. What do you think?

Well, the downloaders know about the details of source options, i.e. is the option :git or is it :svn. So if we’re talking about isolation I think the downloaders would be the better place.

Regarding the cp version I just meant that it would be a lot less needed as usually the pod specs don't need to be updated.

Gotcha. I think you’re correct, which would make me very happy :)

@fabiopelosin
Copy link
Member Author

Btw, instead of ‘bleeding’ I would prefer ‘head’, or ‘latest’. There might be even better options.

lets go with :head?

Well, the downloaders know about the details of source options, i.e. is the option :git or is it :svn. So if we’re talking about isolation I think the downloaders would be the better place.

Gotcha.

@alloy alloy closed this in f88e26c Jul 13, 2012
jzapater pushed a commit to jzapater/CocoaPods that referenced this pull request Sep 17, 2013
@fabiopelosin
Merge pull request CocoaPods#392 from dlackty/fix-uninitialized-constant

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode
2e314d7 
[Rakefile] fix uninitialized constant Pathname error.
alloy added a commit that referenced this pull request Oct 25, 2014
@alloy
[HEAD] Move logic from Specification to Installer/Downloader.
e537bd3 
Closes #392.

Incidentally touched ALL THE FILES.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
3 participants
@fabiopelosin @travisbot @alloy