On Tue, Nov 12, 2013 at 3:51 PM, Marcus (OOo) <marcus.m...@wtnet.de> wrote: > Am 11/11/2013 10:33 PM, schrieb Rob Weir: > >> On Mon, Nov 11, 2013 at 3:21 PM, Marcus (OOo)<marcus.m...@wtnet.de> >> wrote: >>> >>> Am 11/11/2013 04:12 PM, schrieb Jürgen Schmidt: >>> >>>> On 11/11/13 3:59 PM, Rob Weir wrote: >>>>> >>>>> >>>>> On Mon, Nov 11, 2013 at 3:32 AM, Shenfeng Liu<liush...@gmail.com> >>>>> wrote: >>>>>> >>>>>> >>>>>> Hi, all, >>>>>> It was one month since 4.0.1 release. And I noticed some some >>>>>> great >>>>>> works >>>>>> are going to be delivered soon. e.g. the IA2 framework from Steve, the >>>>>> Mac >>>>>> 64-bit support from Herbert, and Windows Patch mechanism from Andre. >>>>>> >>>>>> So I'm thinking, is it a good time to start the 4.1 plan now? We >>>>>> should >>>>>> deliver those great value to our users through a formal release ASAP! >>>>>> And >>>>>> IMO, even only the 3 items above can be enough for a release to be >>>>>> called >>>>>> 4.1. We also want to do OOXML improvement by integrating OSBA patches, >>>>>> and >>>>>> enhance user experience like in-place Input Field, and many other >>>>>> things... >>>>>> While, I think we can keep the continuous improvement across releases. >>>>>> From >>>>>> the record breaking download number since 4.0 and 4.0.1, I feel that >>>>>> keeping regular release is very important to response to our users, >>>>>> attract >>>>>> more new comers, and bring this product to success. >>>>>> >>>>>> So I suggest we start the 4.1 plan now, and set a target date. >>>>>> Since >>>>>> 4.0 >>>>>> was in July, 4.0.1 was in Oct, I feel some time in 1Q will be a good >>>>>> time >>>>>> for 4.1. >>>>>> >>>>> >>>>> Hi Simon, >>>>> >>>>> Something to think about: After 4.0.0 we discussed having a public >>>>> beta with out next major release. If we think this is worth doing, >>>>> then we should plan on two dates: 1) A public beta data, and 2) a >>>>> final release date. For the beta to be useful I think we would want >>>>> it to last 3-4 weeks, enough time to process any new bug reports, >>>>> identify any critical regressions, and fix them. >>>> >>>> >>>> >>>> 4 weeks between both is a minimum form my pov >>>> >>>> But having a beta is of course the route we should take. >>> >>> >>> >>> What about taking into account to keep the possibility to release a >>> second >>> Beta version? It can include fixes for the most nasty and prominent bugs. >>> >> >> Well, hopefully we do some amount of testing before we have a beta. >> So the goal should be for the beta to have no "nasty and prominent" >> bugs. The beta is a form of insurance and a way of setting >> expectations. >> >> For example, I think these two scenarios are technically equivalent: >> >> a) release 4.1.0 after normal testing >> >> b) release 4.1.1 to fix major bugs that we missed in 4.1.0 testing. >> >> and >> >> a') release 4.1.0 beta after normal testing >> >> b') release 4.1.0 GA after fixing important bugs found in beta > > > Sure but we want to do a testing phase in public and not just technically. > > >> These are technically the same, and take approximately the same amount >> of time. The difference is in user expectations. A "beta" >> designation tells the cautious user to avoid it. It encourages users >> who are willing to take more risk and help us by giving feedback. It >> also helps preserve the brand reputation by ensuring that the actual >> GA releases are high quality. >> >> (If we're not careful the users will develop a sense to avoid all >> x.y.0 releases, believing them to be low quality. Other products have >> run into that problem, even with x.y.1 and x.y.2 releases. I think it >> is better if we can avoid having that kind of reputation.) > > > Intersting, one can understand your arguments as points to *do* a second > Beta release. ;-) > > >> A 2nd beta might be necessary in some rare cases, but I think in most >> cases we fix the critical bugs found in the beta and just do normal >> re-testing of those areas in a Release Candidate. > > > Still no point not to do a second release. > > But before you go on with writting, please understand my suggestion as > simple suggestion. I don't want to force it. When you deny it with a short > post, then it's fine. No need to find many arguments that speak (maybe) > against it. ;-) >
I'm not necessarily opposed to have 2, or even 3 betas. (Ha!). But I say let the facts, not preconceptions, determine what we do. Let's do a beta, look at the results, discuss and then determine the next steps. I *predict* that only one beta will be needed. But I'm not insisting on it. Regards, -Rob > Marcus > > > > >>> If we agree on that, we should expand the timeframe to 6 or more weeks. >>> >>> My 2 ct. >>> >>> Marcus >>> >>> >>> >>> >>>>>> I suggest to update the 4.1 planning wiki[1] and: >>>>>> (1) Set the target date. >>>>>> (2) Clean up the planning list, starting from leaving only the active >>>>>> items, and moving the rest to project backlog[2]. >>>>>> >>>>>> Any suggestion/comments? >>>>>> >>>>>> >>>>>> [1] >>>>>> >>>>>> >>>>>> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1+Release+Planning >>>>>> [2] https://cwiki.apache.org/confluence/display/OOOUSERS/Project+Blog >>>>>> >>>>>> >>>>>> - Shenfeng (Simon) > > > --------------------------------------------------------------------- > 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
