Am 09/09/2016 09:11 AM, schrieb Andrea Pescetti:
Patricia Shanahan wrote:
https://cwiki.apache.org/confluence/display/OOOUSERS/Release+Planning+Template
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
https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1.2 ; 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.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
