: > 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
On Mon, May 16, 2011 at 7:41 PM, Chris Hostetter
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 likel
: 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
: 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
On Mon, May 16, 2011 at 1:30 PM, Robert Muir wrote:
> On Mon, May 16, 2011 at 7:10 AM, Simon Willnauer
> 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 will
On Mon, May 16, 2011 at 7:10 AM, Simon Willnauer
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
+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,
ce
+1 for 3.2.
Mike
http://blog.mikemccandless.com
On Sat, May 14, 2011 at 12:32 AM, Shai Erera 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 th
+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 t
On Fri, May 13, 2011 at 6:40 PM, Grant Ingersoll 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 m
On Fri, May 13, 2011 at 6:40 PM, Grant Ingersoll 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 m
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,
12 matches
Mail list logo
