I think "Affects version" applies only to what's been released. If a bug is discovered on trunk it shouldn't have any "affects version" and only "fix for".
Once you make a release, even a rc, the affects field can point to it (4.0rc1, 4.0rc2...). Dawid On Tue, Mar 6, 2012 at 8:58 PM, Uwe Schindler <u...@thetaphi.de> wrote: > Hi, > > > > I was thinking about that already: Currently we have lots of issues with > “Affects Version” = 4.0 and then “fix version” also 4.0. This makes no sense > in my opinion and also confuses users after the release of 4.0. I would > prefer to change all those issues to have an affects version that is > something different, like “4.x”, “4.pre”,… > > > > The problem we have now is that when 4.0 is out and somebody opens a bug > against it, it will also have 4.0. So I would like to change all those > affects versions to something telling that its not affecting 3.x, but > something inbetween, a prerelease-state. So all those bugs would have 4.pre > with a fix of 4.0, later bugs will have 4.0 with fix version 4.1, 4.2,… > > > > What do you think? What “version” name for unreleased trunk would you > prefer? > > > > ----- > > Uwe Schindler > > H.-H.-Meier-Allee 63, D-28213 Bremen > > http://www.thetaphi.de > > eMail: u...@thetaphi.de > > > > From: Shai Erera [mailto:ser...@gmail.com] > Sent: Tuesday, March 06, 2012 7:43 AM > To: dev@lucene.apache.org > Subject: Re: ideas for alphas/betas? > > > > I agree. > > Maybe we should also tag issues as 4.0-alpha, 4.0-beta in JIRA? For > 4.0-alpha we'll tag all the issues that are expected to change the index > format, and 4.0-beta all the issues that require API changes? > > Shai > > On Tue, Mar 6, 2012 at 5:20 AM, Robert Muir <rcm...@gmail.com> wrote: > > Just thinking ahead a bit: since 4.0 will really be a pretty big > release, we have mentioned on the list a few times the ideas of > alphas/betas. > I like the idea of trying to iterate towards a release here, as I > think there will be numerous packaging and documentation issues, > forget about > any real bugs or API problems. > > I was thinking that in order to actually get people to use and test > these things, we should try to make them more than just nightly > builds. > > Here are some quick ideas: > > Alpha: > We won't change the index format unless necessary to fix a bug > > Beta: > We won't change public apis or configuration files unless necessary > to fix a bug > > Any opinions? > We could always add more caveats if needed, but the less the better. > > -- > lucidimagination.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
