openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patricia Shanahan <>
Subject Re: 4.1.4 Release Manager?
Date Thu, 15 Sep 2016 19:53:59 GMT
I believe we should always have a point release, based on the last fully 
stable and released version, ready for code check-in: Release manager 
identified, branch created, release-blocker flags created.

That shortens the latency from identifying an urgent fix to having the 
fix in our users' hands.

The point releases should involve relatively little change, all related 
to things we need to do urgently.

The last 4.1.x that we get to that ready state will never ship - 4.2.0 
will overtake it.

On 9/15/2016 12:25 PM, Phillip Rhodes wrote:
> I like this idea... 4.1.3 and 4.1.4 in the near-term, and then 4.2.0 in
> early 2017.  Feels like a good rhythm to aim for.
> Phil
> On Sep 15, 2016 15:14, "Marcus" <> wrote:
>> Am 09/15/2016 05:44 PM, schrieb Pedro Giffuni:
>>> I am rather amazed by the idea of 4.1.4, shouldn't we release
>>> 4.2.0 instead? I mean ...
>>> - I thought the idea behind 4.1.3 was to make a quick fix for
>>> 4.1.2 and to give more time for the 4.2.0 release process.
>>> - the code in trunk has over two years of development and is
>>> more secure than what lives in the 41* branch. It is rather
>>> disappointing to not see the code out sooner.
>>> I believe you should continue as Release Manager for 4.1.4,
>>> or 4.2.0; the changes for 4.1.3 will already have to be
>>> included in future releases and we could benefit from the
>>> momentum of the dot release. Your vacations should also
>>> not be a problem as other people are likely to be in
>>> vacations during December as well.
>> I still think we should put more QA effort into a 4.2.0 as we have changed
>> to many things. I cannot remember anymore which libraryies we have changed
>> in the last time. So, at least this is a risk in my eyes that deserves much
>> more attention.
>> Up to now I think tests where done here and there, e.g., when using a
>> 4.2.0 dev build for daily tasks. But I would like to see more efforts for
>> deeper tests before release this.
>> So, a fast 4.1.3 and a 4.1.4 still this year *and* then a 4.2.0 for the
>> beginning of next year (new year, new game ;-) ) would be a nice outlook.
>> And as an additional advantage - when we agree on this - this roadmap that
>> can be published, too. *)
>> However, my 2ct.
>> *) Just a note for everyone:
>> Discussing a topic here on a public mailing list does *not* mean that it
>> is automatically published.
>> It's the result of a discussion that can be declared published (here on
>> this mailing list) or made published (e.g., with a blog post). I think I'm
>> not the only one who makes a fine but clear difference bewteen "something
>> is public" and "something is published". Just wanted to mention this. ;-)
>> Marcus
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

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

View raw message