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.
Marcus
On Sep 15, 2016, at 3:25 PM, Phillip Rhodes<motley.crue....@gmail.com> 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
