openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus <>
Subject Re: [PROPOSAL] Managing branches for future releases
Date Wed, 25 Oct 2017 17:44:39 GMT
Am 25.10.2017 um 01:00 schrieb Patricia Shanahan:
> On 10/24/2017 2:34 PM, Kay Schenk wrote:
>> On 10/24/2017 01:25 PM, Andrea Pescetti wrote:
>>> I'm starting a short series of occasional posts to capture the 
>>> current collective state of mind on the next release. I'll float them 
>>> here for refinement or lazy consensus, and then we may want to reuse 
>>> this text in wiki or blog posts to avoid repeating the same concepts 
>>> over and over.
>>> Let's start with branches.
>>> We all wish 4.1.4 to be the last 4.1.x release.
>>> We currently have an AOO415 branch at 
>>> ; this 
>>> branch is a copy of AOO414 (that resulted in OpenOffice 4.1.4). The 
>>> AOO415 branch will result in a release ONLY if we have some important 
>>> bug fixes to release and trunk is not ready yet. No new features, 
>>> even small enhancements, are added to it. No commits to AOO415 happen 
>>> without appropriate mailing list discussions (dev or security, 
>>> depending on cases).
>>> Trunk is where all development happens. It will be branched for a new 
>>> release (like, an AOO420 branch - name still provisional) when the 
>>> code is mature: beta or even RC. Until then, we simply keep working 
>>> on trunk as we are doing now.
>>> In case we need to commit to a branch, any changes are still 
>>> committed to trunk first and then merged to branches using SVN merge 
>>> in all situations when this is possible (i.e., when there are no 
>>> merge conflicts). The mergeinfo for AOO414 and AOO415 isn't clear, so 
>>> we'll have to make sure that trunk contains all fixes done there (or 
>>> equivalent in case of conflicts) and, done that, we commit to AOO415 
>>> only if:
>>> 1. The fix is important and agreed upon on the relevant list
>>> 2. The commit is done with "svn merge" starting from a trunk commit
>>> This will ensure that we can shift the focus to trunk while still 
>>> keeping a branch that remains ready for a quick release if needed. If 
>>> we are never in this situation, the next release will be from the 
>>> current trunk and AOO415 will never result in a release.
>>> Regards,
>>>    Andrea.
>> Would it be more clear to just remove the AOO415 branch and only 
>> re-instate it if needed (hopefully not). I don't see anything in 
>> AOO415 that wasn't included in AOO414.
> The decision to keep the 4.1.5 branch around came out of a discussion on
> the security mailing list. The potential problem is that someday we may
> be faced with a bug for which we need to get a fix out into the field as
> soon as possible.
> Because of the sheer size of AOO, it takes time to get set up for a
> release. The idea is to do as much as we can to prepare without
> committing to a release. I have a check-out of AOO415 built. As the
> version number changes get incorporated I'll update and rebuild. Not
> having to wait for the branch to be prepared, check it out, and do a
> full build reduces by about a day the time it would take from knowing a
> fix to having it built, tested, and checked in.
> I would like to make this an on-going policy. As soon as we ship 4.2.0,
> we remove the AOO415 branch but create AOO421, identical except for
> version numbers to AOO420, ready in case of an emergency fix.

This is an good and cheap idea to speed things up.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message