On 11/21/12 4:22 PM, Rob Weir wrote: > On Wed, Nov 21, 2012 at 9:32 AM, Regina Henschel > <rb.hensc...@t-online.de> 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 >> >> >>> >>> 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. >> >> 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. >> > > I don't think we have the QA capacity to do a full release in > February. I'm trying to build up that team with more volunteers, but > I'd be concerned that with current levels we could not both do a > February release and do the preparatory work we need to do to write up > test cases for a bigger 4.0 release. > > IMHO the new languages are more critical. We don't have any critical > bug fixes in the trunk (that I know of). So I wonder if another > solution is to release additional languages on the 3.4.1 branch? That > kind of mini-release would not require as much retesting, since the > code would not change.
that was part of my post. Having the new translations released on base of 3.4.1. I don't completely disagree to the argumentation of Regina but I believe we should skip a 3.5 and should concentrate on the next bigger release. We can of course change the plan when we get serious bug report and security fixes. We will keep trunk stable and bigger changes should be done on a branch anyway. We have already discussed to drop binfilter and a 4.0 would be the correct version for this drop. Juergen > > -Rob > > >> 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. >> >> >>> >>> 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. >> >> Kind regards >> Regina
