[rules-dev] Quite a few commits on master that look like bug fixes are not on the 5.2.x branch and are not in CR1 (and final)

[Ansgar Konermann]

Am 01.05.2011 09:51, schrieb Geoffrey De Smet:
> Hi guys,
>
> Since the branch was made on Friday morning, there have been quite a
> few commits on master.
> 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.
>
> 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,
> so *those commits will not be in CR1 (and final).*

Hi Geoffrey, hi all,

I'm relatively new to the development process of drools, but the amount
of cherrypicking necessary seems a bit overwhelming to me.

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.

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.

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

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.

Looking forward to your comments.

Best regards

Ansgar


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20110501/cdc690c2/attachment.html