Re: [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)

Am 01.05.2011 09:51, schrieb Geoffrey De Smet: 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