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 Thu, 26 Oct 2017 18:27:12 GMT
Am 26.10.2017 um 07:03 schrieb Peter kovacs:
> Am 25. Oktober 2017 21:25:42 MESZ schrieb Marcus <>:
>> Sure, it's not yet written in stop. But when we need to build it it has to be.
>> Furthermore, when releasing from "test" or "release" or similar, what
>> to
>> do with these branches? I hope you do not suggest "then we can recycle
>> them and reuse for the next build". ;-)
> Why do you think it is a problem to go by state?

I cannot see what is behind the names. "test" - from what? Is it still 
for 4.1.x or the new 4.2.0 or what? I really think it is not clear for 

And again:
Never, never, ever reuse a branch that has seen a release. You will 
destroy the history. In the worst case you will loose the overview and 
therefore loose time when you actually don't have it.

Creating a new branch just after we have released a version is fast and 


>>> Am 25. Oktober 2017 19:44:39 MESZ schrieb Marcus
>> <>:
>>>> 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
>>>> 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
>>>>>>> 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
>>>>>>> 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.
>>>> +1
>>>> This is an good and cheap idea to speed things up.
>>>> Marcus

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

View raw message