Le 21/08/2014 15:17, Jacopo Cappellato a écrit :
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.
That would have my agreement
Jacques
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
