Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of lilyzhao8@gmail.com
 designates 209.85.216.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAP-ksojb97_mk84yMCw1xxk8O_DY3RCWfQFePa9JyqeVmYwiaA@mail.gmail.com>
References: 
 <CAP-ksojb97_mk84yMCw1xxk8O_DY3RCWfQFePa9JyqeVmYwiaA@mail.gmail.com>
Date: Thu, 3 May 2012 17:03:00 +0800
Message-ID: 
 <CAO+9X+UoFmw611UcaGSFv3BDnWmsdEECwb=2BkWhFdg49PKBPA@mail.gmail.com>
Subject: Re: What do we need to do in BZ after AOO 3.4 is released?
From: Xia Zhao <lilyzhao8@gmail.com>
To: ooo-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=20cf30051590142e2f04bf1e123d

--20cf30051590142e2f04bf1e123d
Content-Type: text/plain; charset=ISO-8859-1

Suggest we add AOO 340 version as official release. And for those existing
opening defects, basically they should be moved to this version as well.
But considering we are not sure if many old defects still valid for AOO
3.4, it's better add one version as OOO and change all the defects before
AOO 3.4 to this version. To be honest, I am not sure how we handle these
large volume of old defects. From QA view, I'd like monitor those high
severity defects and verify them against AOO 340+ to check if they exist as
well.

Once AOO 340 is announced, all users can submit their feedback against AOO
340.

Also branch version should be provide to track against which version
volunteer should report issue.

For component, I totally agree Regina's suggestion.

Also one target version filed is need to track the fixed stream for given
bug.

Best regards,

Lily

2012/5/1 Rob Weir <robweir@apache.org>

> Today, among the 100 version strings the users need to scroll through
> in BZ, we have "AOO340-dev".
>
> What do we want after we release AOO 3.4?
>
> Add AOO340?  (Or just rename AOO340-dev to AOO340?)
>
> Add AOO341-dev?
>
> Add AOO450-dev?
>
> Also, are there any "products" that can be removed or demoted to
> "components" under another product?   What we have now is simpler than
> what we had with OOo, but it is still very complicated with a lot of
> "dead wood" at the top level.
>
> -Rob
>

--20cf30051590142e2f04bf1e123d--