<Using Unreleased Features
There may be times when you may want to test an upcoming feature in CocoaPods. At times code for such features may be already available in a 'feature branch'. This document is based on an existing Pull Request which can/will change with time, as such it may be out of date slightly.
<Two Options
Use a Gemfile
This isn't covered in this guide, but instead in Using a Gemfile. This is a simpler technique, but requires you to remember to use bundle exec
before running any pod
command.
Set up a local dev copy of CocoaPods
The technique to run a branch version of CocoaPods is:
- Install
Bundler
if not already installed (installation instructions can be found at bundler.io) - Clone a copy of CocoaPods locally.
- Check out the version to the branch you want.
- Run
bundle install
to get CocoaPods set up. - Use the full path to the new
pod
binary, instead of the one installed via rubygems.
Then when you want to update you go back to that local install and run git pull
, then bundle install
again.
<Real world walk-through
Let's use @mrackwitz's Swift Pull Request CocoaPods#2835 as a example. Note, the swift
branch does not exist anymore. You can see all the current branches here.
Clone a local copy
By looking at the subheading mrackwitz wants to merge 85 commits into master from swift
you can infer that this pull request comes from a branch on the CocoaPods repo. If it looked like Pull Request CocoaPods#2880 ([...] CocoaPods:master from samdmarshall:xclegacy-build-setting-build-dir-fix
) then you could see that it comes from the samdmarshall fork and you would need to clone from that repo.
Cloning a local copy