Re: 3.2.0 (or 3.1.1)

2011-05-16 Thread 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,

Re: 3.2.0 (or 3.1.1)

2011-05-16 Thread Simon Willnauer
On Mon, May 16, 2011 at 1:30 PM, Robert Muir rcm...@gmail.com wrote: On Mon, May 16, 2011 at 7:10 AM, Simon Willnauer simon.willna...@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

Re: 3.2.0 (or 3.1.1)

2011-05-16 Thread Chris Hostetter
: 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

Re: 3.2.0 (or 3.1.1)

2011-05-16 Thread Chris Hostetter
: 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

Re: 3.2.0 (or 3.1.1)

2011-05-16 Thread Robert Muir
On Mon, May 16, 2011 at 7:41 PM, Chris Hostetter hossman_luc...@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

Re: 3.2.0 (or 3.1.1)

2011-05-16 Thread Chris Hostetter
: 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

Re: 3.2.0 (or 3.1.1)

2011-05-14 Thread Michael McCandless
+1 for 3.2. Mike http://blog.mikemccandless.com On Sat, May 14, 2011 at 12:32 AM, Shai Erera ser...@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

3.2.0 (or 3.1.1)

2011-05-13 Thread Grant Ingersoll
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,

Re: 3.2.0 (or 3.1.1)

2011-05-13 Thread 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