Github: maintain multiple releases of a gem

(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 ?

create a branch and keep switching (but never merge)

This is pretty much the standard for maintenance versions.

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.

I personally follow this:

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.

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 ?

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.

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/.

Rob B.
[email protected] http://AgileConsultingLLC.com/
[email protected] http://GaslightSoftware.com/