I agree with that it might be better to have no affects version. But having an affects version allows us to mark issues only relevant to the 4.x branch. Otherwise I cannot sort for issues that only affect 4.x, but have not yet a fix version.
For me it is easy to remove all Affects Version = 4.0 markers, but that’s destructive. If I add a new version (4.pre) and then update all affects versions to this new one, I loose nothing. That’s the idea. ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -----Original Message----- > From: dawid.we...@gmail.com [mailto:dawid.we...@gmail.com] On Behalf Of > Dawid Weiss > Sent: Tuesday, March 06, 2012 9:16 PM > To: dev@lucene.apache.org > Subject: Re: ideas for alphas/betas? > > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
