# Github: maintain multiple releases of a gem **URL:** \ **Category:** Ruby\ **Created:** [October 17, 2010, 4:13pm UTC](https://www.ruby-forum.com/t/github-maintain-multiple-releases-of-a-gem/197624 "2010-10-17T16:13:48Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![Dobai-Pataky\_BSSSSl](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/77aa72/32.png) [@Dobai-Pataky\_BSSSSl](https://www.ruby-forum.com/u/Dobai-Pataky_BSSSSl)\ **Post date:** [October 17, 2010, 4:13pm UTC](https://www.ruby-forum.com/t/github-maintain-multiple-releases-of-a-gem/197624/1 "2010-10-17T16:13:48Z")
(Apologies if i’ve posted before. Can’t find it here). I wish to maintain 2 releases of a gem: version 1.1.x and version 1.2.x. Mostly, 1.1.x is a maintenance version. What is the github workflow: - create a repo clone for each release - create a branch and keep switching (but never merge) So now each branch has its own Rakefile/gemspec which is no longer related. Is this safe ? Any other things that i need to take care of, or are useful ? ---
**Author:** ![sentinel](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/fbc32d/32.png) [@sentinel](https://www.ruby-forum.com/u/sentinel)\ **Post date:** [October 17, 2010, 5:12pm UTC](https://www.ruby-forum.com/t/github-maintain-multiple-releases-of-a-gem/197624/2 "2010-10-17T17:12:09Z")
> create a branch and keep switching (but never merge) This is pretty much the standard for maintenance versions. ---
**Author:** ![sentinel](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/fbc32d/32.png) [@sentinel](https://www.ruby-forum.com/u/sentinel)\ **Post date:** [October 17, 2010, 7:22pm UTC](https://www.ruby-forum.com/t/github-maintain-multiple-releases-of-a-gem/197624/3 "2010-10-17T19:22:19Z")
Steve K. wrote in post #954946: > > create a branch and keep switching (but never merge) > > This is pretty much the standard for maintenance versions. I wish someone would elaborate just to give me confidence. So now CHANGELOG Rakefile, gemspec, and of course all source, diverge for good. Thanks. ---
**Author:** ![sentinel](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/fbc32d/32.png) [@sentinel](https://www.ruby-forum.com/u/sentinel)\ **Post date:** [October 17, 2010, 7:30pm UTC](https://www.ruby-forum.com/t/github-maintain-multiple-releases-of-a-gem/197624/4 "2010-10-17T19:30:20Z")
I personally follow this: > **[A successful Git branching model](https://nvie.com/posts/a-successful-git-branching-model/)** > > In this post I present a Git branching strategy for developing and releasing software as I’ve used it in many of my projects, and which has turned out to be very successful. ---
**Author:** ![sentinel](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/fbc32d/32.png) [@sentinel](https://www.ruby-forum.com/u/sentinel)\ **Post date:** [October 18, 2010, 1:49pm UTC](https://www.ruby-forum.com/t/github-maintain-multiple-releases-of-a-gem/197624/5 "2010-10-18T13:49:38Z")
Ah, yes, I never noticed that. If you want to keep a 1.1 release, you’d just leave the 1.1 branch around, I’d imagine. Or, if it’s gone, start a new branch from the 1.1 tag. ---
**Author:** ![sentinel](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/fbc32d/32.png) [@sentinel](https://www.ruby-forum.com/u/sentinel)\ **Post date:** [October 18, 2010, 8:18am UTC](https://www.ruby-forum.com/t/github-maintain-multiple-releases-of-a-gem/197624/6 "2010-10-18T08:18:17Z")
Great link. I still have a question about multiple versions that i don’t think is answered in that post. You’ve got a bug fix identified in 1.2 which also applies to 1.1 (maint). Do you apply the change separately to both branches ? Or is it applied to 1.1 and then merged with 1.2 or viceversa. I am really afraid about this cherry-picking thing – it seems to work on tiny dummy branches, but on the real thing it just pulls in everything despite saying “interactive”. In the example above, release-\* is a temporary branch. Should i keep it permanent. Or should I keep a “master-_" for other versions and branch "release-_” from it ? ---
**Author:** ![sentinel](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/fbc32d/32.png) [@sentinel](https://www.ruby-forum.com/u/sentinel)\ **Post date:** [October 19, 2010, 6:21am UTC](https://www.ruby-forum.com/t/github-maintain-multiple-releases-of-a-gem/197624/7 "2010-10-19T06:21:26Z")
Rob B. wrote in post #955099: > On Oct 18, 2010, at 2:18 AM, Rahul K. wrote: > Are you thinking about git rebase here? > > You merge and rebase entire branches, but cherry-pick is one commit at > a time. > > -Rob Yes, i was mistaking with rebase. thx. ---
**Author:** ![sentinel](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/fbc32d/32.png) [@sentinel](https://www.ruby-forum.com/u/sentinel)\ **Post date:** [October 18, 2010, 2:30pm UTC](https://www.ruby-forum.com/t/github-maintain-multiple-releases-of-a-gem/197624/8 "2010-10-18T14:30:47Z")
On Oct 18, 2010, at 2:18 AM, Rahul K. wrote: > I am really afraid about this cherry-picking thing – it seems to work > on tiny dummy branches, but on the real thing it just pulls in > everything despite saying “interactive”. Are you thinking about git rebase here? When you git cherry-pick only a single commit is applied to the branch that you’re cherry-picking to. If you have a big fix commit that you create on the 1.2 branch, you’d cherry-pick that onto the 1.1 branch (or create a 1.1.1 or 1.1- p1 branch depending on your conventions) and _also_ cherry-pick that commit onto your development branch (you wouldn’t want the bug to resurface in 2.0, right?) You merge and rebase entire branches, but cherry-pick is one commit at a time. -Rob > In the example above, release-\* is a temporary branch. Should i keep > it > permanent. Or should I keep a “master-_" for other versions and branch > "release-_” from it ? > > – > Posted via [http://www.ruby-forum.com/](http://www.ruby-forum.com/). Rob B. removed\_email\_address@domain.invalid [http://AgileConsultingLLC.com/](http://AgileConsultingLLC.com/) removed\_email\_address@domain.invalid [http://GaslightSoftware.com/](http://GaslightSoftware.com/)