+1 having a new feature branch, and then merge after review AND
automated tests.
On 21/08/14 17:40, Jacques Le Roux wrote:
Le 21/08/2014 07:41, Jacopo Cappellato a écrit :
On Aug 20, 2014, at 10:26 PM, Jacques Le Roux
<[email protected]> wrote:
This is one reason which would refrain me to jump right now. With of
course all the burden and especially the inherent risks of permutation.
I think that Pierre's idea of a branch is a reasonable compromise
Jacques
Of course, if we will ever try the switch to Gradle, this would be
done in the trunk only, not backported to releases; so the
instability period will only affect the trunk.
This is exactly the purpose of trunk vs release branches.
The fact that there are persons that use the trunk in production, and
that don't want it too change much because this may cause them to
work to keep their custom tools/code up-to-date, is a burden that
slows down the evolution of OFBiz.
Jacopo
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
