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" <marcus.m...@wtnet.de> 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: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
