> relevant to the 4.x branch. Otherwise I cannot sort for issues that only > affect 4.x, but have not yet a fix version.
If an issue doesn't have a "fix for" then it's a problem with the issue's description I think (that should be fixed?). I admit the concept of affects/fix for was unclear to me at the beginning when I was starting with Jira (we have our own install in Carrot2). What I explained is what we've come to agree on and is based on trial-and-error really. It just worked best for us. Having "affects version" set to a non-released artefact name is not really informative and only pollutes the set of suggestions with names that are not really pointing to anything. There is the "labels" field where you can set arbitrary markers if you so desire. Dawid > > 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: [email protected] > > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of >> Dawid Weiss >> Sent: Tuesday, March 06, 2012 9:16 PM >> To: [email protected] >> 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 <[email protected]> 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: [email protected] >> > >> > >> > >> > From: Shai Erera [mailto:[email protected]] >> > Sent: Tuesday, March 06, 2012 7:43 AM >> > To: [email protected] >> > 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 <[email protected]> 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: [email protected] For >> > additional commands, e-mail: [email protected] >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] For additional >> commands, e-mail: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
