3.2.0 (or 3.1.1)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

3.2.0 (or 3.1.1)

Grant Ingersoll-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: 3.2.0 (or 3.1.1)

Robert Muir
On Fri, May 13, 2011 at 6:40 PM, Grant Ingersoll <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: 3.2.0 (or 3.1.1)

Ryan McKinley
In reply to this post by Grant Ingersoll-2
On Fri, May 13, 2011 at 6:40 PM, Grant Ingersoll <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: 3.2.0 (or 3.1.1)

Shai Erera
+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 <[hidden email]> wrote:

> On Fri, May 13, 2011 at 6:40 PM, Grant Ingersoll <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: 3.2.0 (or 3.1.1)

Michael McCandless-2
+1 for 3.2.

Mike

http://blog.mikemccandless.com

On Sat, May 14, 2011 at 12:32 AM, Shai Erera <[hidden email]> 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 <[hidden email]> wrote:
>> On Fri, May 13, 2011 at 6:40 PM, Grant Ingersoll <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: 3.2.0 (or 3.1.1)

Simon Willnauer
+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
<[hidden email]> wrote:

> +1 for 3.2.
>
> Mike
>
> http://blog.mikemccandless.com
>
> On Sat, May 14, 2011 at 12:32 AM, Shai Erera <[hidden email]> 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 <[hidden email]> wrote:
>>> On Fri, May 13, 2011 at 6:40 PM, Grant Ingersoll <[hidden email]> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: 3.2.0 (or 3.1.1)

Robert Muir
On Mon, May 16, 2011 at 7:10 AM, Simon Willnauer
<[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: 3.2.0 (or 3.1.1)

Simon Willnauer
On Mon, May 16, 2011 at 1:30 PM, Robert Muir <[hidden email]> wrote:

> On Mon, May 16, 2011 at 7:10 AM, Simon Willnauer
> <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: 3.2.0 (or 3.1.1)

Chris Hostetter-3
In reply to this post by Shai Erera

: 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: 3.2.0 (or 3.1.1)

Chris Hostetter-3
In reply to this post by Robert Muir

: 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: 3.2.0 (or 3.1.1)

Robert Muir
On Mon, May 16, 2011 at 7:41 PM, Chris Hostetter
<[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: 3.2.0 (or 3.1.1)

Chris Hostetter-3

: > 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: [hidden email]
For additional commands, e-mail: [hidden email]