I'd be interested in https://issues.apache.org/jira/browse/SOLR-10962 making it into 7.0 if there's time but wouldn't want to block progress.
Christine From: [email protected] At: 06/27/17 07:30:47 To: [email protected] Subject: Re: Release planning for 7.0 Erick, sure. If you think it'd take longer, could you mark that as a blocker so I hold back moving ahead with the release process? -Anshum On Mon, Jun 26, 2017 at 11:28 PM Anshum Gupta <[email protected]> wrote: Hi Alan, Sorry for the delay in replying but go ahead and commit this. I'm still trying to work through the 8.0 version bump test failures. If you don't make it by the time I push the branches, kindly commit to all the branches, else I'll make sure that your commit makes it to all of those. -Anshum On Mon, Jun 26, 2017 at 3:21 AM Erik Hatcher <[email protected]> wrote: I will get https://issues.apache.org/jira/browse/SOLR-10874 into 7.0 and branch 6x in the next few days - I’ll merge to whatever branches are needed at the time. Erik On Jun 19, 2017, at 10:45 AM, Anshum Gupta <[email protected]> wrote: Hi everyone, Here's the update about 7.0 release: There are still unresolved blockers for 7.0. Solr (12): https://issues.apache.org/jira/browse/SOLR-6630?jql=project%20%3D%20Solr%20AND%20fixVersion%20%3D%20%22master%20(7.0)%22%20and%20resolution%20%3D%20Unresolved%20and%20priority%20%3D%20Blocker Lucene (None): https://issues.apache.org/jira/issues/?jql=project%20%3D%20%22Lucene%20-%20Core%22%20AND%20fixVersion%20%3D%20%22master%20(7.0)%22%20AND%20resolution%20%3D%20Unresolved%20AND%20priority%20%3D%20Blocker Here are the ones that are unassigned: https://issues.apache.org/jira/browse/SOLR-6630 https://issues.apache.org/jira/browse/SOLR-10887 https://issues.apache.org/jira/browse/SOLR-10803 https://issues.apache.org/jira/browse/SOLR-10756 https://issues.apache.org/jira/browse/SOLR-10710 https://issues.apache.org/jira/browse/SOLR-9321 https://issues.apache.org/jira/browse/SOLR-8256 The ones that are already assigned, I'd request you to update the JIRA so we can track it better. In addition, I am about to create another one as I wasn’t able to extend SolrClient easily without a code duplication on master. This brings us to - 'when can we cut the branch'. I can create the branch this week and we can continue to work on these as long as none of these are 'new features' but I'd be happy to hear what everyone has to say. I know there were suggestions around a 6.7 release, does anyone who's interested in leading that have a timeline or an idea around what features did you want in that release? If yes, I’d really want to wait until at least the branch for 6.7 is cur for the purpose of easy back-compat management and guarantee. Also, sorry for being on radio silence for the last few days. I’d been traveling but now I’m back :). -Anshum Gupta On Sun, Jun 18, 2017 at 8:57 AM Dennis Gove <[email protected]> wrote: I've committed the most critical changes I wanted to make. Please don't hold up on a v7 release on my part. Thanks! Dennis On Tue, Jun 13, 2017 at 9:27 AM, Dennis Gove <[email protected]> wrote: Hi, I also have some cleanup I'd like to do prior to a cut of 7. There are some new stream evaluators that I'm finding don't flow with the general flavor of evaluators. I'm using https://issues.apache.org/jira/browse/SOLR-10882 for the cleanup, but I do intend to be complete by June 16th. Thanks, Dennis On Sat, Jun 10, 2017 at 11:21 AM, Ishan Chattopadhyaya <[email protected]> wrote: Hi Anshum, I would like to request you to consider delaying the branch cutting by a bit till we finalize the SOLR-10574 discussions and make the changes. Alternatively, we could backport the changes to that branch after you cut the branch now. Regards, Ishan On Sat, Jun 3, 2017 at 1:02 AM, Steve Rowe <[email protected]> wrote: > On Jun 2, 2017, at 5:40 PM, Shawn Heisey <[email protected]> wrote: > > On 6/2/2017 10:23 AM, Steve Rowe wrote: > >> I see zero benefits from cutting branch_7x now. Shawn, can you describe why >> you think we should do this? >> >> My interpretation of your argument is that you’re in favor of delaying >> cutting branch_7_0 until feature freeze - which BTW is the status quo - but >> I don’t get why that argues for cutting branch_7x now. > > I think I read something in the message I replied to that wasn't > actually stated. I hate it when I don't read things closely enough. > > I meant to address the idea of making both branch_7x and branch_7_0 at > the same time, whenever the branching happens. Somehow I came up with > the idea that the gist of the discussion included making the branches > now, which I can see is not the case. > > My point, which I think applies equally to branch_7x, is to wait as long > as practical before creating a branch, so that there is as little > backporting as we can manage, particularly minimizing the amount of time > that we have more than two branches being actively changed. +1 -- Steve www.lucidworks.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
