<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
Am 01.05.2011 09:51, schrieb Geoffrey De Smet:
<blockquote cite="mid:ipj3db$9v3$1@dough.gmane.org" type="cite">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
Hi guys,<br>
<br>
Since the branch was made on Friday morning, there have been quite
a few commits on master.<br>
Some of these are refactorings/features/improvements, which we
don't want on the 5.2.x as they will jeopardize the stability of
the release.<br>
<br>
But quite a few of those commits are bug fixes and many of those
bug fixes haven't been cherry-picked to the 5.2.x,<br>
so <b>those commits will not be in CR1 (and final).</b><br>
</blockquote>
<br>
Hi Geoffrey, hi all,<br>
<br>
I'm relatively new to the development process of drools, but the
amount of cherrypicking necessary seems a bit overwhelming to me.<br>
<br>
As CR1 is probably more 'stable' than master, I guess that it might
help to just merge into the master all commits which were originally
made to CR1. After all, fixes which were made to the release branch
should also be incorporated into the mainline, shouldn't they? Each
developer could then switch his local repository between the CR1 and
master branch, depending on with which branch he'd like to work
(release fixes should be committed to CR1 branch, regular
development to master). This way, the CR branch becomes more and
more stable while the master continues to evolve independently.<br>
<br>
I also did not quite get why multiple CR/release branches are
created _from the master_ (that's what I understood of how it
currently works; correct me if I'm wrong). As the release should be
as stable and error-free as possible, committing bug fixes to the
same release branch until all relevant bugs are fixed seems more
natural to me. Re-creating a CR branch from master multiple times
bears the risk of introducing *new* bugs from master into the
release.<br>
<br>
Merging commits from the CR/release-branch into the master can
easily be automated, unless conflicts occurr (then of course they
need to be resolved manually).<br>
<br>
We apply a similar scheme at work, and automated the merge down from
release/bugfix branch into master using our CI server. Works like a
charm. Whenever an automatic merge fails due to conflicts, we get a
red build in our XV information radiator so we know we have to fix
it.<br>
<br>
Looking forward to your comments.<br>
<br>
Best regards<br>
<br>
Ansgar<br>
<br>
<br>
</body>
</html>