Am 11/12/2013 10:36 PM, schrieb Rob Weir:
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
Great, then you have understood what I wanted to say.
Marcus
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
