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 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.) 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. Regards, -Rob > 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
