openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus <>
Subject Re: 4.1.4 Release Manager?
Date Thu, 15 Sep 2016 20:33:00 GMT
Am 09/15/2016 09:30 PM, schrieb Jim Jagielski:
> Any real reason to name it 4.2.0 ?

as I don't know what your intention of this short sentence is, I feel 
that also short answer like "Yes, of course" is maybe not helping. ;-)

The only alternative would be 5.0. Sure, we have many code changes 
already done in trunk. However, these are far too less when it comes to 
visibility - that is to say, significant improvements that the user can 
see and use. Therefore 4.2.0 is the best number to express the current 
content of trunk.

BTW (for all, not only Jim):
The following is the release schema that we are using for OpenOffice.

1. Major releases would be a X.y.z (like 4.0.0)

The X implies we have done major changes like a new program module, new 
installers, micro modules instead of the big monolithic block, 
changed/new API etc. These releases are coming from a new branch of trunk.

2. Minor releases would be a x.Y.z (like 4.1.0)

The Y means we have improved or new features of Calc, changed shape 
object in Impress, new translations which would include new strings, 
etc. These releases are coming either from a new branch of the one used 
for the major release.

3. Micro releases would be a x.y.Z (like 4.1.2)

Z is taken for bugfixes only and should not contain bigger things that 
would be better put into a minor release. These releases are coming from 
a new branch of the one used for the minor release.


>> On Sep 15, 2016, at 3: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:

View raw message