(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 ?
--
Posted via http://www.ruby-forum.com/.
create a branch and keep switching (but never merge)
This is pretty much the standard for maintenance versions.
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 ?
--
Posted via http://www.ruby-forum.com/.
Steve Klabnik 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.
--
Posted via http://www.ruby-forum.com/\.
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".
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 Biedenharn
Rob@AgileConsultingLLC.com http://AgileConsultingLLC.com/
rab@GaslightSoftware.com http://GaslightSoftware.com/
On Oct 18, 2010, at 2:18 AM, Rahul Kumar wrote:
I personally follow this:
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.
--
Posted via http://www.ruby-forum.com/\.