github: maintain multiple releases of a gem

[Rahul Kumar]

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

 

[Steve Klabnik]

create a branch and keep switching (but never merge)


This is pretty much the standard for maintenance versions.

 

[Rahul Kumar]

Steve Klabnik wrote in post #954946:

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.

 

[Steve Klabnik]

I personally follow this:
http://nvie.com/posts/a-successful-git-branching-model/

 

[Rahul Kumar]

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 ?

 

[Steve Klabnik]

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.

 

[Rob Biedenharn]

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

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 ?

Rob Biedenharn
(e-mail address removed) http://AgileConsultingLLC.com/
(e-mail address removed) http://GaslightSoftware.com/

 

[Rahul Kumar]

Rob Biedenharn wrote in post #955099:

On Oct 18, 2010, at 2:18 AM, Rahul Kumar 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.