openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus <>
Subject Re: Release process and 4.1.3
Date Fri, 09 Sep 2016 16:45:20 GMT
Am 09/09/2016 09:11 AM, schrieb Andrea Pescetti:
> Patricia Shanahan wrote:
>> It is what I would want to do for a major release with user interface
>> changes.
> Yes, that one is the template for a 4.2.0, not for a 4.1.3 release.

but you still can take this list, make a copy of it and delete 
everything that makes no sense for a bugfix release - you already 
mentioned the string freeze and translation phases.

With some additional notses from Patricia we have then a new, smaller 
list which can be put into Wiki, too.

>> We also need something far, far more agile for getting simple bug fix
>> releases out quickly and easily. I propose using 4.1.3 as a test case
>> for a stripped down process.
> Actually, 4.1.2 was exactly this. Your starting point should thus be
> ; just
> copy the wiki page and edit/generalize accordingly.

Sure, but also here no detailed instructions what exactly to do. ;-)

Patricia, I'm sorry but I think you have to ask a bit more than you 
want. But you will find always a helping hand or answer here.

>> No string changes means we do not need the "String freeze" or
>> "Translation phase" steps. No significant changes to external
>> interfaces, combined with a small number of relatively simple fixes,
>> eliminates the "Beta Release" phase.
> This is the difference between a "micro" (third digit) and a "minor"
> (second digit) release. Calling it 4.1.3 implies all of this, barring
> exceptional situations.

in the past we have used the following release version schema:

Major releases would be a X.y.z
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.

Minor releases would be a x.Y.z
This means we have improved or new features of Calc, changed shape 
object in Impress, new translations which would include new strings, etc.

Micro releases would be a x.y.Z
This is taken for bugfixes only. Of course we can agree on exceptions to 
include a few new strings and also translations. But it shouldn't lead 
to bigger things that would be better put into a minor release.

>> We still need to pick the bug fixes to go in the release, construct a
>> release candidate, test it, write release notes etc.
> This is all covered in the link I sent. There might be some steps that
> need better clarification though.


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

View raw message