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 > >> 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 >> > >
