lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler" <>
Subject RE: ideas for alphas/betas?
Date Tue, 06 Mar 2012 19:58:48 GMT


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



Uwe Schindler

H.-H.-Meier-Allee 63, D-28213 Bremen




From: Shai Erera [] 
Sent: Tuesday, March 06, 2012 7:43 AM
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?


On Tue, Mar 6, 2012 at 5:20 AM, Robert Muir <> 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
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

Here are some quick ideas:

 We won't change the index format unless necessary to fix a bug

 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.


To unsubscribe, e-mail:
For additional commands, e-mail:


View raw message