I previously talked about how I used Vrsnr in a Rake task to bump version numbers in “Manage version numbers with this one line command”. At the time, I was using it in an iOS app’s codebase, bumping its build and version numbers as I pushed out beta builds. But, as I worked on that and other apps that use Pippin, I also continuously updated it, and needed to push new versions of its podspec for consumption back in those apps.
In Pippin’s repo, I’m still using the same Rake task as before, but with a few tweaks since I last wrote it (you can see the old version in the old post). Previously, it always popped a stash off the stack at the end, but that wouldn’t be necessary if nothing was stashed as part of running the task. Hence, changes from who knows when would’ve been placed in the working index, confusing the programmer; now it checks if any changes are present before stashing, and only pops a stash if there were changes. Also, it no longer creates a git tag… that’s coming later on in the post.
Afer running this in Pippin’s repo, the podspec’s version has been incremented and the change is committed with a descriptive message:
Updated version from 4.2.0 to 4.3.0 in Pippin.podspec. Next, I run a new Rake task written to release the pod:
This is what creates the git tag we mentioned earlier (using Vrsnr’s
--read function), pushes that tag, and pushes the podspec to the CocoaPods trunk. The nice thing about separating the bumping of version and tagging is it allows you to do any branch work necessary for your git flow before creating the tag, so it doesn’t wind up pointing to orphaned commits or other strange things you might not want.
Once I’ve found something I want to add in Pippin for use in whatever app I’m in at the moment, my flow looks like this:
pod installin the app repo, pointed at my local checkout of Pippin in the Podfile
rake bump[minor](or whatever component needs it), then
pod installwithout the path declaration to pick up the new version from trunk
Five steps to get the changes in my devpod, push them to trunk, and get them back in the app, with everything properly tracked in version control. The only other thing is that path declaration in the app’s Podfile–I don’t like having to hand edit that kind of thing, dirtying my git index. So, I use environment variables:
pod install grabs the production version, and
PIPPIN_PATH=/path/to/.../pippin pod install grabs it from a local checkout (in Fish shell,
env PIPPIN_PATH=/path/to/.../pippin pod install). So, I’m using the latter in step 1, and the former in step 4.
I’m a strong believer in semantic versioning, because it makes reasoning about and automating dependencies easier. Just as well, I strongly believe in maintaining auditability and reproducibility through version control. Vrsnr helps you do both, please consider using it and helping make it better–it’s designed with extensibility in mind, to cover more types of dependencies, ecosystems and platforms!