lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dawid Weiss <dawid.we...@cs.put.poznan.pl>
Subject Re: ideas for alphas/betas?
Date Tue, 06 Mar 2012 20:51:14 GMT
> 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: uwe@thetaphi.de
>
>
>> -----Original Message-----
>> From: dawid.weiss@gmail.com [mailto:dawid.weiss@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 <uwe@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: uwe@thetaphi.de
>> >
>> >
>> >
>> > From: Shai Erera [mailto:serera@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 <rcmuir@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-unsubscribe@lucene.apache.org For
>> > additional commands, e-mail: dev-help@lucene.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
>> commands, e-mail: dev-help@lucene.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message