http://ofbiz.116.s1.nabble.com/Request-to-All-Committers-tp180509p180516.html
on this note, the usage will be high till the next stable release. for
those of us that support clients. So support may be for the bug fixes in
>> Of course, if there is a conflict in the merge or the bug was caused
> after
>> the release branch was done, then this will require more work or won't be
>> necessary.
>
> Determine what bug the bugfix was trying to fix in the trunk. Determine
> if the same bug exists in the release branch. That is the minimum work
> required when applying patches across branches.
>
> As I said before, once the trunk deviates too far from the release
> branch, and it gets difficult to compare "apples to oranges", it may be
> time to discontinue support for that release branch, unless someone
> steps up and says: "there's a whole lot of us still using that branch,
> so let us maintain it".
>
>> BTW, for everyone watching in this sort of overhead is one reason why we
>> haven't been really excited about doing release branches in the past,
>> but still it's great that OFBiz is reaching the level of maturity where
>> this is possible and happening!
>
> In general, the purpose of the release branch is to have a "quieter
> stream" for those who need a situation where "number of bugs fixed is
> greater than the number created". Such a situation is hardly possible
> (nor correct) in the trunk stream.
>
> Bug reports should come in for the release branch, not the trunk. The
> whole point of publishing (and using) the release branch is to get more
> bugfixes and less new bugs. It's best to fix bugs in the release branch
> first, then massage (if necessary) the bugfix for the trunk. Fixing bugs
> on the "quieter stream" should be easier than fixing bugs in the trunk
> where bug phenomena could be compounded by frequent radical changes.
>
> If we find no bug reports coming in for the release branch, then there
> is absolutely no interest in the release branch (or no bugs!). In that
> case, the release branch will progress very slowly to
> maturity/stability, and the whole community will have to live with that.
>
> So, those who had complained like "please don't break existing
> functionality!" should be advised to use the release branch. And those
> who need the "latest and greatest though less tested" can try the trunk.
> And everybody is (or should be) happy.
>
> Jonathon
>
> David E. Jones wrote:
>>
>> To help maintain the release branch, I'd like to ask all committers to
>> keep it in mind as we fix bugs.
>>
>> If you commit a bug fix to the trunk, go ahead and merge it into the
>> release branch as well.
>>
>> This should be pretty easy, just do the following:
>>
>> 1. keep a checkout of the release4.0 branch somewhere on your machine
>> (the full URL is:
>>
https://svn.apache.org/repos/asf/ofbiz/branches/release4.0)
>>
>> 2. after committing to the trunk make note of your commit revision
>> number and go into your release4.0 branch local checkout directory and
>> run something like (replacing the rev number there with the one from
>> your commit):
>>
>> $ ./mergefromtrunk.sh 532994
>>
>> This doesn't take much time and it will make it easier for all of us
>> to keep the release branch updated with the latest bug fixes that go
>> into the trunk. Of course, if there is a conflict in the merge or the
>> bug was caused after the release branch was done, then this will
>> require more work or won't be necessary.
>>
>> BTW, for everyone watching in this sort of overhead is one reason why
>> we haven't been really excited about doing release branches in the
>> past, but still it's great that OFBiz is reaching the level of
>> maturity where this is possible and happening!
>>
>> Thanks,
>> -David
>>
>
>
>
>