Re: Lucene/Solr 6.0.0 Release Branch

- >>> Uwe Schindler >>> H.-H.-Meier-Allee 63, D-28213 Bremen >>> http://www.thetaphi.de >>> eMail: u...@thetaphi.de >>> >>> > -Original Message- >>> > From: Michael McCandless [mailto:luc...@mikemccandless.com] >>> >

Re: [Possibly spoofed] Re: Lucene/Solr 6.0.0 Release Branch

gt; eMail: u...@thetaphi.de >> >> > -Original Message- >> > From: Michael McCandless [mailto:luc...@mikemccandless.com] >> > Sent: Thursday, March 10, 2016 11:13 AM >> > To: Lucene/Solr dev <dev@lucene.apache.org> >> > Subject: Re: [Poss

Re: [Possibly spoofed] Re: Lucene/Solr 6.0.0 Release Branch

..@mikemccandless.com] > > Sent: Thursday, March 10, 2016 11:13 AM > > To: Lucene/Solr dev <dev@lucene.apache.org> > > Subject: Re: [Possibly spoofed] Re: Lucene/Solr 6.0.0 Release Branch > > > > Hi Nick, > > > > Since we are still finding a number of bad bu

RE: [Possibly spoofed] Re: Lucene/Solr 6.0.0 Release Branch

ginal Message- > From: Michael McCandless [mailto:luc...@mikemccandless.com] > Sent: Thursday, March 10, 2016 11:13 AM > To: Lucene/Solr dev <dev@lucene.apache.org> > Subject: Re: [Possibly spoofed] Re: Lucene/Solr 6.0.0 Release Branch > > Hi Nick, > > Sinc

Re: [Possibly spoofed] Re: Lucene/Solr 6.0.0 Release Branch

gt;> >> I already converted MultiPhraseQuery >> (https://issues.apache.org/jira/browse/LUCENE-7064: reviewed and committed >> by Adrien Grand). >> >> >> >> Luc Vanlerberghe >> >> >> >> From: Joel Bernstein [mailto:joels...@gmail.com] >>

Re: [Possibly spoofed] Re: Lucene/Solr 6.0.0 Release Branch

> > > > Luc Vanlerberghe > > > > *From:* Joel Bernstein [mailto:joels...@gmail.com] > *Sent:* maandag 7 maart 2016 21:08 > *To:* lucene dev > *Subject:* [Possibly spoofed] Re: Lucene/Solr 6.0.0 Release Branch > > > > "Major API and bug fixes

RE: [Possibly spoofed] Re: Lucene/Solr 6.0.0 Release Branch

] Sent: maandag 7 maart 2016 21:08 To: lucene dev Subject: [Possibly spoofed] Re: Lucene/Solr 6.0.0 Release Branch "Major API and bug fixes (no features) can be committed without my approval before Friday as long as they're reviewed and approved by another committer." Hmmm, are there re

Re: Lucene/Solr 6.0.0 Release Branch

On Mon, Mar 7, 2016 at 3:07 PM, Joel Bernstein wrote: > As far as > bug fixes needing another committer approval is not something we've done in > the past. Correct. And the burden should not be on any RM to decide either what bug fixes go in or not either... that is asking

Re: Lucene/Solr 6.0.0 Release Branch

> Hmmm, are there really major API changes underway at this point? Major fixes (not changes) if they're needed. (e.g, the types of fixes that have been worked over the weekend to shore up the API for the major release) > As far as bug fixes needing another committer approval is not something

Re: Lucene/Solr 6.0.0 Release Branch

"Major API and bug fixes (no features) can be committed without my approval before Friday as long as they're reviewed and approved by another committer." Hmmm, are there really major API changes underway at this point? As far as bug fixes needing another committer approval is not something we've

Re: Lucene/Solr 6.0.0 Release Branch

I think with all of the volatility surrounding the new Points codec that obvious bug/stability patches like these are OK? I know several folks have been working feverishly the past few days to fix serious (and simplify) 6.0 issues and squash all of the jenkins failures to ensure stability in time

Re: Lucene/Solr 6.0.0 Release Branch

I just want to clarify you(Nick) / our expectations about this release branch. It seems, based on issues I've seen like LUCENE-7072, that we can commit to the release branch without your permission as RM. If this is true, then I presume the tacit approval is okay so long as it's not a new

Re: Lucene/Solr 6.0.0 Release Branch

On 3/4/2016 7:35 AM, Robert Muir wrote: > On Fri, Mar 4, 2016 at 6:00 AM, Vanlerberghe, Luc > wrote: >> Basically, they apply changes at the lowest release for which the change is >> applicable and then merge the change upwards to the other releases and >>

Re: Lucene/Solr 6.0.0 Release Branch

On Fri, Mar 4, 2016 at 6:00 AM, Vanlerberghe, Luc wrote: > Basically, they apply changes at the lowest release for which the change is > applicable and then merge the change upwards to the other releases and > eventually to trunk. > This just creates a worse

Re: Lucene/Solr 6.0.0 Release Branch

@lucene.apache.org Subject: [Possibly spoofed] Re: Lucene/Solr 6.0.0 Release Branch Mike, I'll fix the TestBackwardsCompatibility. The mistake was to freeze the 6x branch in the first place. The release branch is the one which should be frozen. I specifically asked the RM to cut the branch to let

Re: Lucene/Solr 6.0.0 Release Branch

Sure, I will. Thanks ! On Thu, Mar 3, 2016 at 11:20 AM, Nicholas Knize wrote: > I quickly skimmed the patches. I'm OK with them being backported to 6.0. > Can you mark the Fix Version/s accordingly? > > Thanks! > > On Thu, Mar 3, 2016 at 1:11 PM, Anshum Gupta

Re: Lucene/Solr 6.0.0 Release Branch

I quickly skimmed the patches. I'm OK with them being backported to 6.0. Can you mark the Fix Version/s accordingly? Thanks! On Thu, Mar 3, 2016 at 1:11 PM, Anshum Gupta wrote: > The releases are demanding, specially major versions, so thanks for all > the effort Nick.

Re: Lucene/Solr 6.0.0 Release Branch

The releases are demanding, specially major versions, so thanks for all the effort Nick. I would like to commit SOLR-8423 and SOLR-8725 to 6.0. They aren't blockers but are bugs and the patch for both are ready. If you are fine with it, I'll commit to 6.0 else, I'd push it out with 6.1.

Re: Lucene/Solr 6.0.0 Release Branch

> hours (acceptable), not days (unacceptable). ++ I definitely agree with this. And it looks like the time period here was less than a day? > there were multiple questions about it from more than one person over a couple days ?? I do not see these questions? They're certainly not in this

Re: Lucene/Solr 6.0.0 Release Branch

First, Nick, thanks for your RM work. > On Mar 3, 2016, at 12:53 PM, Nicholas Knize wrote: > > The mistake was to freeze the 6x branch in the first place. The release > > branch is the one which should be frozen. > > I certainly agree with this. However, over a week ago

Re: Lucene/Solr 6.0.0 Release Branch

I wouldn't read so, to be honest. This isn't so convoluted: https://git-scm.com/docs/git-diff Quote: git diff [--options] [--] […] This is to view the changes between two arbitrary . git diff [--options] .. [--] […] This is synonymous to the previous form. I use it all the time (never used

Re: Lucene/Solr 6.0.0 Release Branch

Nearly all of my git knowledge is from possibly wrongheaded stack overflow posts - in this case where chaiyachaiya said "git diff b1..b2, show you what is in b2 that is not in b1. So git diff b1..b2 and git diff b2..b1

Re: Lucene/Solr 6.0.0 Release Branch

> The mistake was to freeze the 6x branch in the first place. The release branch is the one which should be frozen. I certainly agree with this. However, over a week ago there was a request to hold off on creating the 6_0 branch until Jenkins settled with a 6x. I received no push back on this

Re: Lucene/Solr 6.0.0 Release Branch

> (with minor solr/CHANGES.txt fixups) and then diffing both directions: > > git diff branch_6_0..branch_6x > git diff branch_6x..branch_6_0 Wait, can it ever be assymetric? I'd say it's impossible -- it should always be a "reverse" diff of the another? Dawid

Re: Lucene/Solr 6.0.0 Release Branch

I compared the state of branch_6x and branch_6_0 after Mike merged LUCENE-7062 by cherry-picking Shalin's 6.1-only commits into my local branch_6_0: e4712bb028849f9a9b202651728c1f5c0a224374 (SOLR-8722) 97db2d0b932ceae17fc6ab442af0b32f54928e05 (Adding version 6.1.0)

Re: Lucene/Solr 6.0.0 Release Branch

On Thu, Mar 3, 2016 at 10:58 AM, Robert Muir wrote: > I think mike has not merged his checkindex work but I am surprised to > see merge conflicts? OK I was able to merge my 6.x push to 6.0 with no conflicts, a good sign! > Mike can you make sure your readint/readvint >

Re: Lucene/Solr 6.0.0 Release Branch

On Thu, Mar 3, 2016 at 11:30 AM, Shalin Shekhar Mangar wrote: > I'll fix the TestBackwardsCompatibility. Thanks. > The mistake was to freeze the > 6x branch in the first place. The release branch is the one which > should be frozen. I specifically asked the RM to cut

Re: Lucene/Solr 6.0.0 Release Branch

> > > - > > Uwe Schindler > > H.-H.-Meier-Allee 63, D-28213 Bremen > > http://www.thetaphi.de > > eMail: u...@thetaphi.de > > > > > >> -Original Message----- > >> From: Shalin Shekhar Mangar [mailto:shalinman...@gmail.com] &g

Re: Lucene/Solr 6.0.0 Release Branch

> The rest of the problem was because I am new to Git -- > in subversion a release branch is always copied from the server so > pulling latest changes locally before creating the branch did not > cross my mind. FYI, just as a side note for those interested in version control systems. Contrary to

Re: Lucene/Solr 6.0.0 Release Branch

Mike, I'll fix the TestBackwardsCompatibility. The mistake was to freeze the 6x branch in the first place. The release branch is the one which should be frozen. I specifically asked the RM to cut the branch to let others progress but I received no replies -- which is why I was forced to do it

Re: Lucene/Solr 6.0.0 Release Branch

Shalin, In the future please don't jump the gun like this? It has caused a lot of unnecessary chaos. It should be the RM, and only the RM, that is doing things like creating release branches, bumping versions, etc., at release time. Also, your changes to bump the version on 6.x seem to be

Re: Lucene/Solr 6.0.0 Release Branch

On Thu, Mar 3, 2016 at 10:48 AM, Steve Rowe wrote: > Feature freeze for a release should not block development. +1 Mike McCandless http://blog.mikemccandless.com - To unsubscribe, e-mail:

Re: Lucene/Solr 6.0.0 Release Branch

> Mike can you make sure your readint/readvint mismatch and other important > bugfixes are not missing here? Thanks Rob, I'll confirm this fix made it to 6.0. And, yes, I haven't merged LUCENE-7062 to 6.0 yet: it hit merge conflicts when I last tried, I thought (at the time) because Shalin's

Re: Lucene/Solr 6.0.0 Release Branch

I took a look (by doing merge --squash from branch_6x to review changes), and it mostly looks good, but i was surprised to see these conflicts: both modified: lucene/core/src/java/org/apache/lucene/index/CheckIndex.java both modified:

Re: Lucene/Solr 6.0.0 Release Branch

Shalin, I will take a look. -- Steve www.lucidworks.com > On Mar 3, 2016, at 10:25 AM, Shalin Shekhar Mangar > wrote: > > I cherry-picked the following missing commits. I think I got all of > the missing ones but another set of eyes would be good. > > Cherry-pick

Re: Lucene/Solr 6.0.0 Release Branch

eMail: u...@thetaphi.de > > >> -Original Message- >> From: Shalin Shekhar Mangar [mailto:shalinman...@gmail.com] >> Sent: Thursday, March 03, 2016 4:26 PM >> To: dev@lucene.apache.org >> Subject: Re: Lucene/Solr 6.0.0 Release Branch >> >> I cherry-

RE: Lucene/Solr 6.0.0 Release Branch

- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: Shalin Shekhar Mangar [mailto:shalinman...@gmail.com] > Sent: Thursday, March 03, 2016 4:26 PM > To: dev@lucene.apache.org > Subject: Re: Lu

Re: Lucene/Solr 6.0.0 Release Branch

I cherry-picked the following missing commits. I think I got all of the missing ones but another set of eyes would be good. Cherry-pick successful 3cbc48e LUCENE-7059: always visit 1D points in sorted order; fix tie-break but in BKDWriter; fix BKDWriter to pass on maxMBSortInHeap to

Re: Lucene/Solr 6.0.0 Release Branch

Since this is the first major release since cutting over to git the intent was to first create the 6x branch and create 6_0 once Jenkins was stable with the new branches (version changes, backcompat, etc). This meant a slight gap between creating the 6x and 6_0 branch, and a temporary feature

Re: Lucene/Solr 6.0.0 Release Branch

Hmm I think I created the branch without pulling the latest code. I'll fix. On Thu, Mar 3, 2016 at 6:41 PM, Robert Muir wrote: > This is missing a bunch of yesterday's branch_6x changes. Some of > david smiley's spatial work, at least one of my commits. > > On Thu, Mar 3, 2016

Re: Lucene/Solr 6.0.0 Release Branch

This is missing a bunch of yesterday's branch_6x changes. Some of david smiley's spatial work, at least one of my commits. On Thu, Mar 3, 2016 at 5:10 AM, Shalin Shekhar Mangar wrote: > FYI, I have created the branch_6_0 so that we can continue to commit > stuff intended

Re: Lucene/Solr 6.0.0 Release Branch

FYI, I have created the branch_6_0 so that we can continue to commit stuff intended for 6.1 on master and branch_6x. I have also added the 6.1.0 version on branch_6x and master. On Wed, Mar 2, 2016 at 9:51 PM, Shawn Heisey wrote: > On 3/2/2016 4:19 AM, Alan Woodward wrote:

Re: Lucene/Solr 6.0.0 Release Branch

On 3/2/2016 4:19 AM, Alan Woodward wrote: > Should we create a separate branch_6_0 branch for the feature-freeze? > I have stuff to push into master and that should eventually make it > into 6.1, and it will be easy to forget to backport stuff if there's a > week before I can do that… +1 When I

Re: Lucene/Solr 6.0.0 Release Branch

Gus, we are now in feature freeze for 6.0 but we should have a 6.1 soon-ish. Lucene/Solr averages a minor release every 6 weeks or so. On Wed, Mar 2, 2016 at 9:34 PM, Gus Heck wrote: > Hi, just noticed this thread. I've been pushing hard to get >

Re: Lucene/Solr 6.0.0 Release Branch

Hmm if I add a 6.1 section now, before the branch_6_0 is created, Nick will have to manually remove the 6.1 section. Nick, I have some stuff to commit for 6.1 but I can hold on for a bit if you are going to create the branch_6_0 soon. On Wed, Mar 2, 2016 at 9:18 PM, Shalin Shekhar Mangar

Re: Lucene/Solr 6.0.0 Release Branch

Hi, just noticed this thread. I've been pushing hard to get https://issues.apache.org/jira/browse/SOLR-8349, which was partly funded by a customer into 6.0 ... I submitted it many months ago, but only got review a few weeks ago. On Wed, Mar 2, 2016 at 10:48 AM, Shalin Shekhar Mangar <

Re: Lucene/Solr 6.0.0 Release Branch

+1 to a separate branch_6_0 for the freeze. I'm going to create a 6.1 section in CHANGES.txt. On Wed, Mar 2, 2016 at 4:49 PM, Alan Woodward wrote: > Should we create a separate branch_6_0 branch for the feature-freeze? I > have stuff to push into master and that should

Re: Lucene/Solr 6.0.0 Release Branch

Should we create a separate branch_6_0 branch for the feature-freeze? I have stuff to push into master and that should eventually make it into 6.1, and it will be easy to forget to backport stuff if there's a week before I can do that… Alan Woodward www.flax.co.uk On 2 Mar 2016, at 09:39,

Re: Lucene/Solr 6.0.0 Release Branch

Thanks Mike! I'll have a look at addVersion.py and see if it needs to be updated. On Wed, Mar 2, 2016 at 3:50 AM, Michael McCandless < luc...@mikemccandless.com> wrote: > TestBackCompat seems angry on master ... I'll try to fix it. Seems > like addVersion.py got confused maybe :) > > Mike

Re: Lucene/Solr 6.0.0 Release Branch

TestBackCompat seems angry on master ... I'll try to fix it. Seems like addVersion.py got confused maybe :) Mike McCandless http://blog.mikemccandless.com On Wed, Mar 2, 2016 at 4:39 AM, Nicholas Knize wrote: > Yes! The 6x branch is in feature freeze but bug fixes are still

Re: Lucene/Solr 6.0.0 Release Branch

Yes! The 6x branch is in feature freeze but bug fixes are still OK. We'll let jenkins settle over the next week or so before beginning the actual release process. On Wed, Mar 2, 2016 at 3:30 AM, Michael McCandless < luc...@mikemccandless.com> wrote: > Thanks Nick! > > Is it OK if I push

Re: Lucene/Solr 6.0.0 Release Branch

e > > > > *From:* Nicholas Knize [mailto:nkn...@gmail.com] > *Sent:* Wednesday, March 02, 2016 10:15 AM > *To:* dev@lucene.apache.org > *Subject:* Re: Lucene/Solr 6.0.0 Release Branch > > > > I created branch_6x and updated the version in master to 7.0.0 but it

Re: Lucene/Solr 6.0.0 Release Branch

Thanks Nick! Is it OK if I push LUCENE-7059 (6.0 blocker I opened yesterday)? Point values issues... Mike McCandless http://blog.mikemccandless.com On Wed, Mar 2, 2016 at 4:15 AM, Nicholas Knize wrote: > I created branch_6x and updated the version in master to 7.0.0 but it

RE: Lucene/Solr 6.0.0 Release Branch

ct: Re: Lucene/Solr 6.0.0 Release Branch I created branch_6x and updated the version in master to 7.0.0 but it looks like I do not have jenkins karma to configure builds for the new 6x branch. Can someone have a look at configuring the builds? On Mon, Feb 29, 2016 at 11:40 PM, Nicholas Kniz

Re: Lucene/Solr 6.0.0 Release Branch

I created branch_6x and updated the version in master to 7.0.0 but it looks like I do not have jenkins karma to configure builds for the new 6x branch. Can someone have a look at configuring the builds? On Mon, Feb 29, 2016 at 11:40 PM, Nicholas Knize wrote: > > Thanks for the

Re: Lucene/Solr 6.0.0 Release Branch

Thanks for the info David! I'll likely update version labels and create the 6X branch late tomorrow or early the next day. Let me know if anyone has an issue with this timing. Thanks, - Nick On Monday, February 29, 2016, david.w.smi...@gmail.com < david.w.smi...@gmail.com> wrote: > I consider

Re: Lucene/Solr 6.0.0 Release Branch

I consider https://issues.apache.org/jira/browse/LUCENE-7056 (a little spatail3d reshuffling) blocker before 6.0 as it's the ideal time to move things around / rename. But I don't mind doing an extra cherry pick in the end if you want to go create the branch without waiting. So I don't know if

Re: Lucene/Solr 6.0.0 Release Branch

Thanks Uwe! Indeed we need branch_6x (and master versions changed) first. I'll plan to get that done Monday and/or Tuesday. Let me know if there are any blockers and I'll send a note to the list before I create the branch. - Nick On Wednesday, February 24, 2016, Uwe Schindler

Re: Lucene/Solr 6.0.0 Release Branch

Thank you for volunteering Nick! Mike McCandless http://blog.mikemccandless.com On Wed, Feb 24, 2016 at 3:23 PM, Nicholas Knize wrote: > With the release of 5.5 and the previous discussion re: 6.0.0 I'd like to > keep the ball moving and volunteer as the 6.0.0 RM. > > If

RE: Lucene/Solr 6.0.0 Release Branch

Hi Nicholas, before we start a branch_6_0 we should do the following: - Start branch_6x as “new stable branch” - Update version numbers in “master” to 7.0 This should be done maybe early next week and then after a while that things settle (also the Jenkins Jobs for

Re: Lucene/Solr 6.0.0 Release Branch

I'd really like to see LUCENE-6993 make it in, but unfortunately, I don't have an ETA on it at this time. On Wed, Feb 24, 2016 at 2:23 PM, Nicholas Knize wrote: > With the release of 5.5 and the previous discussion re: 6.0.0 I'd like to > keep the ball moving and volunteer as

Re: Lucene/Solr 6.0.0 release

Hi Christian, These look like great improvements to Kuromoji, but for the same reasons, I think it's risky to commit these changes at the last minute, not giving Jenkins time to chew on it, etc. I think they should just go into 6.0 instead, which is coming out shortly after 5.5? A release is

Re: Lucene/Solr 6.0.0 release

On Tue, Feb 9, 2016 at 3:14 PM, Anshum Gupta wrote: > Thanks Mike for volunteering! You're welcome! > I wanted to get SOLR-8619 in for 5.5.0, I'll mark that as a blocker as it > can potentially cause data loss. I'm currently working on that. Hmm this is a little

Re: Lucene/Solr 6.0.0 release

Hello, I'd like to get LUCENE-6837 and LUCENE-3922 into 5.5. I believe I can have them merged this week. Best, Christian > On Feb 5, 2016, at 02:42, Nicholas Knize wrote: > > +1 for 5.5.0 release. I have 2 issues I'd like to get in for 5.5: LUCENE-6930 >

Re: Lucene/Solr 6.0.0 release

Thanks Mike for volunteering! I wanted to get SOLR-8619 in for 5.5.0, I'll mark that as a blocker as it can potentially cause data loss. I'm currently working on that. I also have a bunch of Solr related stuff I wanted to commit before moving on the 6.0 path so back-compat wouldn't be a problem,

Re: Lucene/Solr 6.0.0 release

Thanks Christine, I'll wait for SOLR-8621 before cutting the branch. Mike McCandless http://blog.mikemccandless.com On Tue, Feb 9, 2016 at 2:46 PM, Christine Poerschke (BLOOMBERG/ LONDON) wrote: > +1 for 5.5.0 release. > > Am about to mark SOLR-8621 as a blocker,

Re: Lucene/Solr 6.0.0 release

+1 for 5.5.0 release. Am about to mark SOLR-8621 as a blocker, it's basically 'done' (with collaboration and help from Shai) but a signature change for MergePolicyFactory will be needed to support SOLR-5730 (which ideally would also be included in 5.5.0 and which hopefully can be wrapped up

Re: Lucene/Solr 6.0.0 release

Thanks Nick and Anshum, I'll volunteer to be RM. If there are blocker 5.5 issues, please mark them as such in Jira, thanks! I don't think we are rushing here ... it was a little under a month ago when I had thought "in or week or two" let's cut the 6.x branch ;) I see 5.5 release as just

Re: Lucene/Solr 6.0.0 release

I think we are in good shape now for 6.0.0? git cutover is done and seems to be going well except for how we name branches Dimensional values are renamed to point values, the API is cleaned up a bit, and you can now search for == (not just ranges), and StoredDocument is removed. We should first

Re: Lucene/Solr 6.0.0 release

+1 for 5.5.0 release. I have 2 issues I'd like to get in for 5.5: LUCENE-6930 and LUCENE-6997 which changes GeoPoint encoding (boosting performance), and graduates these features from sandbox.

Re: Lucene/Solr 6.0.0 release

I have a few things I'd like to get in. I hope to get those in by next week. I think the 5.5 release is an important one for us as the cleanup in 6.0 depends on it. We shouldn't rush it. On Thu, Feb 4, 2016 at 9:42 AM, Nicholas Knize wrote: > +1 for 5.5.0 release. I have 2

Re: Lucene/Solr 6.0.0 release

I don't think we should hold the major release for lots of new large features that are not even started yet; they can just as easily be done in a 6.x release. Remember the counterbalance here is major new features that are done (as far as we know!), yet not readily available to users. And moving

Re: Lucene/Solr 6.0.0 release

I agree completely with this approach. There's always another release right around the corner. There's some nice features waiting in trunk. +1 moving forward fairly soon. +1 to 6.0 being the git release if possible. Joel Bernstein http://joelsolr.blogspot.com/ On Fri, Jan 8, 2016 at 2:51 PM,

Re: Lucene/Solr 6.0.0 release

On Fri, Jan 8, 2016 at 2:52 PM Michael McCandless wrote: > I agree it would be nice to have cutover to git by then: are we ready > to open an INFRA issue to do the hard cutover? Or do we still have > things to do on our end? (Thank you Dawid and Mark and Paul and Uwe

Re: Lucene/Solr 6.0.0 release

I'd like to see some visible improvements to the Solr UI before then. Notably a "nodes" pane and a couple of others, so a timescale of "a few months" would be great. Upayavira On Fri, Jan 8, 2016, at 02:34 PM, Noble Paul wrote: > deprecating old API is not yet planned. both will co-exist. > >

Re: Lucene/Solr 6.0.0 release

+1 to that ! Do you have a planned timeline for this? I would want some time to clean up code and also have a deprecation release (5.5 or 5.6) out so we don't have to carry all the cruft through the 6x series. On Fri, Jan 8, 2016 at 4:37 AM, Michael McCandless < luc...@mikemccandless.com> wrote:

Re: Lucene/Solr 6.0.0 release

deprecating old API is not yet planned. both will co-exist. On Fri, Jan 8, 2016 at 7:33 PM, Jan Høydahl wrote: > +1 for getting the ball rolling and decide a date for branch cutting... > > Regarding /v2/ api, isn’t the plan that the new api will co-exist with the > old

Re: Lucene/Solr 6.0.0 release

+1 for getting the ball rolling and decide a date for branch cutting... Regarding /v2/ api, isn’t the plan that the new api will co-exist with the old for some time? If so, it would be acceptible to add the /v2/ API in 6.x and deprecate old api in 6.y? -- Jan Høydahl, search solution architect

Re: Lucene/Solr 6.0.0 release

I was planning to add SOLR-8029 ( Modernize and standardize Solr APIs) to 6.0 it is at least 2-3 months away. If the release is planned after march I would like to get that in. On Fri, Jan 8, 2016 at 1:10 PM, Dawid Weiss wrote: >> I think we should get the ball rolling

Re: Lucene/Solr 6.0.0 release

On 1/8/2016 8:13 AM, Shawn Heisey wrote: > I've only been paying attention to commits for one new major release, so > I can offer some info on 5.0, but not any of the previous major releases. > > Robert created branch_5x on 2014/09/18. Version 5.0.0 was released on > 2015/02/20. That's five

Re: Lucene/Solr 6.0.0 release

What do people thing about waiting to cut the branch until someone has something that shouldn't go into 6.0? Committing will be easier that way. No biggie, maybe Mike's purpose is served by the notice "get your stuff in trunk that you want to go in 6.0 Real Soon Now" ;) As always, since I'm not

Re: Lucene/Solr 6.0.0 release

Couple of items that I am working on that I would like to see in 6.0: SOLR-5944: Updatable DocValues in Solr SOLR-8396: Using Dimensional values in Solr The first one needs some more tests, maybe some refactoring and reviews. The second one requires some dev work, it is at a very early stage. I

Re: Lucene/Solr 6.0.0 release

OK, does this sound like an umbrella JIRA (maybe one for Lucene and one for Solr) for "Things to add for 6.0" to anybody else as a way of organizing? On Fri, Jan 8, 2016 at 8:21 AM, Ishan Chattopadhyaya wrote: > Couple of items that I am working on that I would like to

Re: Lucene/Solr 6.0.0 release

On 1/8/2016 7:52 AM, Upayavira wrote: > I'd like to see some visible improvements to the Solr UI before then. > Notably a "nodes" pane and a couple of others, so a timescale of "a few > months" would be great. I've only been paying attention to commits for one new major release, so I can offer

Re: Lucene/Solr 6.0.0 release

+1 for a 5.x deprecation release so 6.0 can remove old stuff. +1 for a git-based release +1 for at least 3 months for people to finish and stabilize work in progress - April to July seems like the right window to target -- Jack Krupansky On Fri, Jan 8, 2016 at 10:09 AM, Anshum Gupta

Re: Lucene/Solr 6.0.0 release

Some Solr stuff in 6.x that I'm familiar with: ParallelSQL and Cross Data Center Replication These seem like major hunks of functionality as well, so maybe it's time. So what kind of straw-man date are you thinking? Not trying to pin anything down, just thinking about setting priorities

Re: Lucene/Solr 6.0.0 release

> I think we should get the ball rolling for our next major release (6.0.0)? I'd love it to be the first git-based release. :) It'd be a nice milestone change (from infrastructural point of view). Not a blocker, of course. Dawid