When going through and doing a release for ruby_odata, I had a workflow problem that resulted in extra, unneeded, work. I originally posed the question going on three years ago now (wow). You’d think I would remember the solution, but I find that I keep looking for my StackOverflow post where I answered my own question. I figured that was a sign that I should add to the Visoft blog. Before we get to the problem, here’s my basic release workflow for my RubyGems.
Git, Bundler, and RubyGems
I use git for source control whenever I can. The project that I was working on was ruby_odata, my Ruby “wrapper” to interface with Microsoft OData Services. I used to be a huge Microsoft “fanboy” as you know, and have turned very critical of them as of a few years ago. That said, OData Services is really a pretty cool thing. It was magical to be able to have an Entity Framework model, and easy expose it over the web by just adding one service file. Sorry, I digress.
Ok, where were we? Oh yes, git. In addition to git, I like using @nvie‘s gitflow. It makes branching fun. It’s a simple tool, that allows you to issue commands like
git flow release start v0.1.6 and that will start a new git branch, and change you over to that release branch. You make all of your changes, checking them in as you go along, then you can run
git flow release finish v0.1.6 and gitflow will add a tag of
v0.1.6 and merge everything into your
develop branches. Nothing you couldn’t do manually of course, but gitflow makes it a snap.
Duplicate Git Tags
Whoops, there is a problem. The
rake release command goes and tries to tag your git repository with the same tag that gitflow added, resulting in a conflict. I initially just deleted the git tag manually, and then did the release again, this time, successfully. That’s a pain, there must be a better way
-n command-line argument tells git-flow not to tag the branch, so when you do a rake release, it will be tagged correctly.