On Aug 21, 2014, at 12:40 PM, Jacques Le Roux <[email protected]> wrote:
> I think you did not get me right. Like I have explained to Ron, branches are > not only to get stabilised releases. So my idea would be to have a new > feature branch where we can make the desired changes before merging them in > the trunk, when happy with them. > > This is for instance what I did for the jQuery move. What I did also for the > missed Tom Burn's new help (now a Neogia addon I have been told). And what > I'm doing for the SEO branch I created for OFBIZ-5312 which I want to merge > back in trunk before we freeze a branch for the next release. > > So yes it's a bit a burden, but it's a way to (more) safely integrate new > features in the trunk. > > Jacques Experimental branches are useful for running experiments that impact a large amount of code or require several commits (and committers) to be completed; especially when the community is divided about the opportunity to integrate them. The examples you provided belongs to this group... the ant->gradle switch I am not sure because we could easily implement the gradle scripts while leaving the ant scripts in place and then remove the ant scripts only when we will have enough confidence. But really it is too early to talk about how to do this work... at the moment we can just focus on the pros/cons of this switch. Jacopo
