Rob Weir wrote:
On Wed, Nov 21, 2012 at 11:04 AM, Keith N. McKenna
<keith.mcke...@comcast.net> wrote:
Regina Henschel wrote:
Hi Jürgen,
Jürgen Schmidt schrieb:
Hi,
first of all I would like to volunteer again as release manager for our
next release if it's ok for our community.
+1
+1 on that from me also
Second I would like to define with you what our next release will be.
After various discussion and activities on the mailing list and also at
the ApacheCon, I got the impression that the majority would support a
4.0 version as our next release.
I'm not in favor of an version 4.0 as next release. The changes have
listed below would justify a version "4.0". But I doubt, that they are
possible in a time frame, I see for the next release.
I am with Regina on this one. I do not see a Jan or Feb time frame as
feasible for the design and implementation of a new and still a comfortable
bit of padding to deal with the inevitable gremlins that will sneak out of
the woodwork to assure the kind of quality release that is expected of
OpenOffice and that we expect of ourselves.
Uh, Juergen never suggested January or Feburary as a time frame for
4.0. So I don't see how one can dismiss a 4.0 proposal as being
unfeasible based on dates that he never suggested. Maybe we should
ask Juergen what timeframe he had in mind for 4.0? Of course, it
might be possible to do both, provided we have volunteers willing to
own testing and release management for 3.5.
-Rob
As I re-read the post you are correct Rob and I apologize to Juergen for
reading to much between the lines. What timeframe were you considering
for a 4.0 release Juergan?
Regards
Keith
We have released 3.4.1 in August 2012, so a good time for a next release
would be February 2013. That release would get a lot of bug fixes and
new languages, but no new features. Remembering the difficulties doing
releases around December/January I think, it cannot be earlier. But it
should not be later either for to get the valuable language work as soon
as possible.
This proposal makes more sense to me and appears to be a good compromise. It
builds on the work that has been done to fix bugs and it also gets out much
needed and judging by the response for translators, much wanted new
languages.
Making larger changes which justify a new major release means at the
same time, we have to say something about end of life of the 3.x series.
By releasing a 3.5 it gives us an opportunity to prepare our end users that
the 3.x series is coming to end of life and that the next release will have
some exciting changes. Let us not forget that often the success of major
changes to a mature product such as AOO are as much do to good marketing as
they are to the hard work of developers and testers.
We are planning some bigger UI changes for the next release (sidebar)
and such UI changes are always a good indicator for a new major release
to signal our users bigger changers. I know Ariel has also some
incompatible changes regarding add-ons in the pipeline that would also
fit in a major release.
Not to forget the internal changes in Draw.
I noticed some discussion around a new visual design and a bigger
rebranding and this is a further reason for a major release.
I think it is time to define this more concrete and focus in more detail
on the work that is needed and required to bring a good and stable
release on the road. Our goal should be to continue the success of 3.4
and 3.4.1.
If nobody will complain I will start to merge the started 3.5 and 4.0
planning into one combined planning later.
The changes are so large, that they need a lot of testing. The printing
dialog has been the last large UI change and that has last over a year.
Even when I only take the test time, which is reflected in Bugzilla, I
see eight months "CWS printerpullpages".
The internal changes in Draw are not visible, but because they effect
the whole office, they need a lot of testing too.
I do not think, that a good tested release with such changes would be
possible before July. Therefore I argue for not merging the planning,
but release a 3.5 based on the current trunk (approximately) and then a
version 4.0 containing large changes in autumn 2013.
I believe it is important
that we concentrate on our next release. If you think a rebranding is
important and you want to drive it, please start immediately. If you
want to bring in some new features, please communicate it on the list
and start working on it. Let us work on the plan for the next release in
an open and transparent way.
Setting a feature freeze day?
Besides the next major release we should also continue the discussion on
further language packs based on 3.4.1 to make the latest translations
available as soon as possible.
One way to make these language packs available would be to integrate the
new translations on the AOO34 branch, build the language packs and a new
source release based on this revision. The effort should be minimal as
long as we don't integrate bugfixes.
On the other hand a release is of course a lot of work and we can focus
on releasing these new languages together with 4.0. The question is if
we do have the resources for releasing the new languages?
Any opinions or feedback?
So my suggestion is to not make 4.0 the next release but do a 3.5
release with bug fixes and further languages in between.
+1 to Regina's proposal to do a 3.5 rather than try to jump straight into
4.0
Regards
Keith
Kind regards
Regina