You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Grant Ingersoll <gs...@apache.org> on 2011/05/14 00:40:01 UTC
3.2.0 (or 3.1.1)
It's been just over 1 month since the last release. We've all said we want to get to about a 3 month release cycle (if not more often). I think this means we should start shooting for a next release sometime in June. Which, in my mind, means we should start working on wrapping up issues now, IMO.
Here's what's open for 3.2 against:
Lucene: https://issues.apache.org/jira/browse/LUCENE/fixforversion/12316070
Solr: https://issues.apache.org/jira/browse/SOLR/fixforversion/12316172
Thoughts?
-Grant
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: 3.2.0 (or 3.1.1)
Posted by Chris Hostetter <ho...@fucit.org>.
: And also, we should adopt that approach going forward (no more bug fix
: releases for the stable branch, except for the last release before 4.0
: is out). That means updating the release TODO with e.g., not creating
: a branch for 3.2.x, only tag it. When 4.0 is out, we branch 3.x.y out
: of the last 3.x tag.
I don't know that we need box ourselves in ... if someone discovers a
massively critical bug the day after 3.2 is released, it's totally
reasonable/sensible to do a quick 3.2.1 release.
That said: i don't know that we have to create the 3.2.x branch when we
create the 3.2 tag ... we can certainly do a lazy instantiation as needed.
Bottom line: 3.x.0 releases are still "feature releases on the stable api
branch", and as long as we can maintain intertia on relatively rapid turn
arround of feature release then great -- but that doens't mean we should
completley rule out having 3.x.y "bug fix" releases.
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: 3.2.0 (or 3.1.1)
Posted by Simon Willnauer <si...@googlemail.com>.
On Mon, May 16, 2011 at 1:30 PM, Robert Muir <rc...@gmail.com> wrote:
> On Mon, May 16, 2011 at 7:10 AM, Simon Willnauer
> <si...@googlemail.com> wrote:
>> the question is if we should backport stuff like LUCENE-2881 to 3.2 or
>> if we should hold off until 3.3, should we do it at all?
>>
>
> I think it depends solely if someone is willing to do the work? The
> only idea i would suggest is if we did such a thing, it would really
> be preferred if it was able to have around 2 weeks of hudson to knock
> out problems?
>
Absolutely, but I think we can safely move that to 3.3 though.. I am
busy with other things right now
simon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: 3.2.0 (or 3.1.1)
Posted by Robert Muir <rc...@gmail.com>.
On Mon, May 16, 2011 at 7:10 AM, Simon Willnauer
<si...@googlemail.com> wrote:
> the question is if we should backport stuff like LUCENE-2881 to 3.2 or
> if we should hold off until 3.3, should we do it at all?
>
I think it depends solely if someone is willing to do the work? The
only idea i would suggest is if we did such a thing, it would really
be preferred if it was able to have around 2 weeks of hudson to knock
out problems?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: 3.2.0 (or 3.1.1)
Posted by Simon Willnauer <si...@googlemail.com>.
+1 for pushing 3.2!!
There have been discussions about porting DWPT to 3.x but I think its
a little premature now and I am still not sure if we should do it at
all. The refactoring is pretty intense throughout all IndexWriter and
it integrates with Flex / Codecs. I am not saying its impossible,
certainly doable but I am not sure if its worth the hassle, lets
rather concentrate on 4.0.
the question is if we should backport stuff like LUCENE-2881 to 3.2 or
if we should hold off until 3.3, should we do it at all?
simon
On Sat, May 14, 2011 at 12:30 PM, Michael McCandless
<lu...@mikemccandless.com> wrote:
> +1 for 3.2.
>
> Mike
>
> http://blog.mikemccandless.com
>
> On Sat, May 14, 2011 at 12:32 AM, Shai Erera <se...@gmail.com> wrote:
>> +1 for 3.2!
>>
>> And also, we should adopt that approach going forward (no more bug fix
>> releases for the stable branch, except for the last release before 4.0
>> is out). That means updating the release TODO with e.g., not creating
>> a branch for 3.2.x, only tag it. When 4.0 is out, we branch 3.x.y out
>> of the last 3.x tag.
>>
>> Shai
>>
>> On Saturday, May 14, 2011, Ryan McKinley <ry...@gmail.com> wrote:
>>> On Fri, May 13, 2011 at 6:40 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>>> It's been just over 1 month since the last release. We've all said we want to get to about a 3 month release cycle (if not more often). I think this means we should start shooting for a next release sometime in June. Which, in my mind, means we should start working on wrapping up issues now, IMO.
>>>>
>>>> Here's what's open for 3.2 against:
>>>> Lucene: https://issues.apache.org/jira/browse/LUCENE/fixforversion/12316070
>>>> Solr: https://issues.apache.org/jira/browse/SOLR/fixforversion/12316172
>>>>
>>>> Thoughts?
>>>>
>>>
>>> +1 for 3.2 with a new feature freeze pretty soon
>>>
>>> ---------------------------------------------------------------------
>>> 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
Re: 3.2.0 (or 3.1.1)
Posted by Michael McCandless <lu...@mikemccandless.com>.
+1 for 3.2.
Mike
http://blog.mikemccandless.com
On Sat, May 14, 2011 at 12:32 AM, Shai Erera <se...@gmail.com> wrote:
> +1 for 3.2!
>
> And also, we should adopt that approach going forward (no more bug fix
> releases for the stable branch, except for the last release before 4.0
> is out). That means updating the release TODO with e.g., not creating
> a branch for 3.2.x, only tag it. When 4.0 is out, we branch 3.x.y out
> of the last 3.x tag.
>
> Shai
>
> On Saturday, May 14, 2011, Ryan McKinley <ry...@gmail.com> wrote:
>> On Fri, May 13, 2011 at 6:40 PM, Grant Ingersoll <gs...@apache.org> wrote:
>>> It's been just over 1 month since the last release. We've all said we want to get to about a 3 month release cycle (if not more often). I think this means we should start shooting for a next release sometime in June. Which, in my mind, means we should start working on wrapping up issues now, IMO.
>>>
>>> Here's what's open for 3.2 against:
>>> Lucene: https://issues.apache.org/jira/browse/LUCENE/fixforversion/12316070
>>> Solr: https://issues.apache.org/jira/browse/SOLR/fixforversion/12316172
>>>
>>> Thoughts?
>>>
>>
>> +1 for 3.2 with a new feature freeze pretty soon
>>
>> ---------------------------------------------------------------------
>> 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
Re: 3.2.0 (or 3.1.1)
Posted by Shai Erera <se...@gmail.com>.
+1 for 3.2!
And also, we should adopt that approach going forward (no more bug fix
releases for the stable branch, except for the last release before 4.0
is out). That means updating the release TODO with e.g., not creating
a branch for 3.2.x, only tag it. When 4.0 is out, we branch 3.x.y out
of the last 3.x tag.
Shai
On Saturday, May 14, 2011, Ryan McKinley <ry...@gmail.com> wrote:
> On Fri, May 13, 2011 at 6:40 PM, Grant Ingersoll <gs...@apache.org> wrote:
>> It's been just over 1 month since the last release. We've all said we want to get to about a 3 month release cycle (if not more often). I think this means we should start shooting for a next release sometime in June. Which, in my mind, means we should start working on wrapping up issues now, IMO.
>>
>> Here's what's open for 3.2 against:
>> Lucene: https://issues.apache.org/jira/browse/LUCENE/fixforversion/12316070
>> Solr: https://issues.apache.org/jira/browse/SOLR/fixforversion/12316172
>>
>> Thoughts?
>>
>
> +1 for 3.2 with a new feature freeze pretty soon
>
> ---------------------------------------------------------------------
> 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
Re: 3.2.0 (or 3.1.1)
Posted by Ryan McKinley <ry...@gmail.com>.
On Fri, May 13, 2011 at 6:40 PM, Grant Ingersoll <gs...@apache.org> wrote:
> It's been just over 1 month since the last release. We've all said we want to get to about a 3 month release cycle (if not more often). I think this means we should start shooting for a next release sometime in June. Which, in my mind, means we should start working on wrapping up issues now, IMO.
>
> Here's what's open for 3.2 against:
> Lucene: https://issues.apache.org/jira/browse/LUCENE/fixforversion/12316070
> Solr: https://issues.apache.org/jira/browse/SOLR/fixforversion/12316172
>
> Thoughts?
>
+1 for 3.2 with a new feature freeze pretty soon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: 3.2.0 (or 3.1.1)
Posted by Chris Hostetter <ho...@fucit.org>.
: > I don't disagree, but the devils advocate argument is "given the relative
: > size of the change sets, testing a 3.1.1 release is likely to be easier
: > then testing a 3.2 release, and the patches commited to the 3.1.x branch
: > are less likely to have introduced new bugs (becuase they only contain bug
: > fixes and not new features"
: thats true, but 3.2 also has better test coverage than 3.1.1 (a couple
: TestIdeas were worked off the list), and its in hudson's rotation
: every half hour.
+1 ... no argument.
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: 3.2.0 (or 3.1.1)
Posted by Robert Muir <rc...@gmail.com>.
On Mon, May 16, 2011 at 7:41 PM, Chris Hostetter
<ho...@fucit.org> wrote:
> I don't disagree, but the devils advocate argument is "given the relative
> size of the change sets, testing a 3.1.1 release is likely to be easier
> then testing a 3.2 release, and the patches commited to the 3.1.x branch
> are less likely to have introduced new bugs (becuase they only contain bug
> fixes and not new features"
>
thats true, but 3.2 also has better test coverage than 3.1.1 (a couple
TestIdeas were worked off the list), and its in hudson's rotation
every half hour.
additionally there's at least one or two test coverage things we can
backport from trunk to 3.2 just because... which seems more productive
than backporting things from branch_3x to a bugfix 3.1.1 branch that
isn't even being tested by hudson.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: 3.2.0 (or 3.1.1)
Posted by Chris Hostetter <ho...@fucit.org>.
: My vote would be to just spend our time on 3.2. people get bugfixes,
: better test coverage, and a couple of new features and optimizations,
: too.
: Is it really going to be harder to release 3.2 than to release 3.1.1?
I don't disagree, but the devils advocate argument is "given the relative
size of the change sets, testing a 3.1.1 release is likely to be easier
then testing a 3.2 release, and the patches commited to the 3.1.x branch
are less likely to have introduced new bugs (becuase they only contain bug
fixes and not new features"
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: 3.2.0 (or 3.1.1)
Posted by Robert Muir <rc...@gmail.com>.
On Fri, May 13, 2011 at 6:40 PM, Grant Ingersoll <gs...@apache.org> wrote:
> It's been just over 1 month since the last release. We've all said we want to get to about a 3 month release cycle (if not more often). I think this means we should start shooting for a next release sometime in June. Which, in my mind, means we should start working on wrapping up issues now, IMO.
>
> Here's what's open for 3.2 against:
> Lucene: https://issues.apache.org/jira/browse/LUCENE/fixforversion/12316070
> Solr: https://issues.apache.org/jira/browse/SOLR/fixforversion/12316172
>
> Thoughts?
>
> -Grant
My vote would be to just spend our time on 3.2. people get bugfixes,
better test coverage, and a couple of new features and optimizations,
too.
Is it really going to be harder to release 3.2 than to release 3.1.1?
we could just announce in advance we'd like to feature freeze 3.2 on
<X date in the future> ?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org