I have to admit I have a hard time following what "WE" decided and what is going on right now. There are several issues and as far as I understand a somewhat reasonable plan to tackle them. Yet, I think we should take a step back and sum up things what the current status is before we get into wars or anything unreasonable. We had a vote on Java 8 on trunk which passed if I remember. Yet, we also need to sort out the back compat issues that robert raised and I think they are valid. The actions we wanna take somehow got mixed into a different discussion ( he java8 vote Steve pointed out) and I think they did have (not saying they would't get) consensus. I feel like things moving too quick here too and they are hard to follow. Can we have a vote for the proposal that is worked on?
On Thu, Sep 18, 2014 at 8:57 PM, Steve Rowe <[email protected]> wrote: > That proposal was on a VOTE thread for a separate issue: moving trunk to > Java8, and literally nobody replied to it. > > Spreading this kind of decision around on several issues and threads and then > assuming that everybody will put them together, understand which version of > the proposal is active at any given second, and then somehow agree, is > ridiculous. > > Steve > > On Sep 18, 2014, at 1:45 PM, Uwe Schindler <[email protected]> wrote: > >> FYI, we are following this proposal: >> http://mail-archives.apache.org/mod_mbox/lucene-dev/201409.mbox/%3CCAOdYfZUpAbYp-omdw=ngjsdzbkvhn2zydobzvj1gdxk+lrt...@mail.gmail.com%3E >> >> Uwe >> >> ----- >> Uwe Schindler >> H.-H.-Meier-Allee 63, D-28213 Bremen >> http://www.thetaphi.de >> eMail: [email protected] >> >> >>> -----Original Message----- >>> From: Uwe Schindler [mailto:[email protected]] >>> Sent: Thursday, September 18, 2014 7:38 PM >>> To: '[email protected]' >>> Subject: RE: [DISCUSS] The next Lucene/Solr release, aka 5.0 is the new 4.11 >>> >>> Hi Steve, >>> >>> Robert is currently backporting the "non-critical" stuff from Lucene 5. >>> There is >>> some code in 5.0, which is not ready to commit (like Lucene Stored >>> Document's API). The approach above was just done like that for ease of >>> handling. In fact, Robert created a "big patch" between trunk an branch_5x >>> and removed all stuff that’s not ready for release. This would then be >>> committed to 5.x branch for release. >>> >>> So the current workflow may be "untypical" but at the end was easier to >>> handle than "reverting" changes in trunk that are not ready to release. >>> >>> We are not going to release the state of the branching today, it was just a >>> step inbetween. After Robert's hard work we will have a large number of >>> changes in 5.0, especially those breaking backwards compatibility (like the >>> final move to Java 7 NIO.2). We are just inbetween at the moment. Stuff >>> that’s unfinished (like we removed WAR file in trunk, but in contrast have >>> no >>> real Lucene Server with main() method, servlet free is not releaseable) were >>> left out. >>> >>> Uwe >>> >>> ----- >>> Uwe Schindler >>> H.-H.-Meier-Allee 63, D-28213 Bremen >>> http://www.thetaphi.de >>> eMail: [email protected] >>> >>> >>>> -----Original Message----- >>>> From: Steve Rowe [mailto:[email protected]] >>>> Sent: Thursday, September 18, 2014 7:26 PM >>>> To: lucene dev >>>> Subject: [DISCUSS] The next Lucene/Solr release, aka 5.0 is the new >>>> 4.11 >>>> >>>> On LUCENE-5944, Robert and Uwe discussed moving trunk to 6.x and >>>> “creating branch_5x”, which I understood to mean: >>>> >>>> svn copy trunk branch_6x >>>> svn move trunk branch_5x >>>> >>>> Today, Robert did: >>>> >>>> svn copy branch_4x branch_5x >>>> >>>> and then Uwe did: >>>> >>>> svn remove branch_4x >>>> >>>> I don’t think this is the way to go. There is huge amount of >>>> deprecation removal that happened on trunk, which will have to be >>>> repeated on branch_5x prior to a release. >>>> >>>> How about we go with releasing what was trunk before today as 5.0? >>>> That will have the same backcompat result as Robert/Uwe’s approach. >>>> >>>> Steve >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] For >>>> additional commands, e-mail: [email protected] >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
