Please find the release notes here: Lucene: https://wiki.apache.org/lucene-java/ReleaseNote70 <https://wiki.apache.org/lucene-java/ReleaseNote70>
Solr: https://wiki.apache.org/solr/ReleaseNote70 <https://wiki.apache.org/solr/ReleaseNote70> I am cleaning up the ‘upgrading from 6x’ section to make it shorter but feel free to either fix/add things to this. I pushed the artifacts last night so there are still about 8 hours to the 24 hours period. I’ll use the 8 hours to fix the website etc. and announce once all of this is wrapped up! -Anshum > On Aug 28, 2017, at 10:46 PM, Varun Thacker <va...@vthacker.in> wrote: > > I don't think holding up the release process infinitely till we stabilize all > the tests is an option. On the other hand getting an RC to build is pretty > difficult ( I am facing the same problem with 6.6.1 ) and I am sure people > will run into this while voting for the release? > > We could identify the top 2/3 tests which fail regularly while building the > RC and either disable them or see if someone volunteers to fix them ? > > On Tue, Aug 29, 2017 at 2:53 AM, Ishan Chattopadhyaya > <ichattopadhy...@gmail.com <mailto:ichattopadhy...@gmail.com>> wrote: > > Those flaky Solr tests are annoying since people will also run into > > failures when > > checking the RC? Should we disable these tests on the 7.0 branch so that > > building > > and verifying this RC isn't annoying to everybody working on this release? > > +1. If it is hampering the release process, I think we should either not > release without fixing them, or disable them for release (building, > verifying). > > On Mon, Aug 28, 2017 at 11:47 PM, Anshum Gupta <ansh...@apple.com > <mailto:ansh...@apple.com>> wrote: > Though those failing tests are annoying, I would not recommend ignoring those > tests. We can manually ignore those test failures when we are testing stuff > out though. > > -Anshum > > > >> On Aug 28, 2017, at 11:10 AM, Adrien Grand <jpou...@gmail.com >> <mailto:jpou...@gmail.com>> wrote: >> >> Those flaky Solr tests are annoying since people will also run into failures >> when checking the RC? Should we disable these tests on the 7.0 branch so >> that building and verifying this RC isn't annoying to everybody working on >> this release? >> >> Le lun. 28 août 2017 à 19:23, Anshum Gupta <ansh...@apple.com >> <mailto:ansh...@apple.com>> a écrit : >> Thanks Adrien! It worked with a fresh clone, at least ant check-licenses >> worked, so I’m assuming the RC creation would work too. >> I’m running that, and it might take a couple of hours for me to create one, >> as a few SolrCloud tests are still a little flakey and they fail >> occasionally. >> >> -Anshum >> >> >> >>> On Aug 28, 2017, at 10:13 AM, Anshum Gupta <ansh...@apple.com >>> <mailto:ansh...@apple.com>> wrote: >>> >>> Adrien, >>> >>> Yes, ant check-licenses fails with the same error, and so does ant validate >>> (from the root dir). This is after running ant clean -f. >>> >>> BUILD FAILED >>> /Users/anshum/workspace/lucene-solr/build.xml:117: The following error >>> occurred while executing this line: >>> /Users/anshum/workspace/lucene-solr/lucene/build.xml:90: The following >>> error occurred while executing this line: >>> /Users/anshum/workspace/lucene-solr/lucene/tools/custom-tasks.xml:62: JAR >>> resource does not exist: analysis/icu/lib/icu4j-56.1.jar >>> >>> I didn’t realize that the dependency was upgraded, and what confuses me is >>> that the file actually exists. >>> >>> anshum$ ls analysis/icu/lib/icu4j-5 >>> icu4j-56.1.jar icu4j-59.1.jar >>> >>> It seems like it’s something that git clean, ant clean clean-jars etc. >>> didn’t fix. This is really surprising but I’ll try and checking out again >>> and creating and RC (after checking for the dependencies). >>> I think ant should be responsible for cleaning this up, and not git so >>> there’s something off there. >>> >>> -Anshum >>> >>> >>> >>>> On Aug 28, 2017, at 8:51 AM, Adrien Grand <jpou...@gmail.com >>>> <mailto:jpou...@gmail.com>> wrote: >>>> >>>> You mentioned you tried to run the script multiple times. Have you run git >>>> clean at some point? Maybe this is due to a stale working copy? >>>> >>>> Le lun. 28 août 2017 à 08:53, Adrien Grand <jpou...@gmail.com >>>> <mailto:jpou...@gmail.com>> a écrit : >>>> Hi Anshum, >>>> >>>> Does running ant check-licenses from the Lucene directory fail as well? >>>> The error message that you are getting looks weird to me since Lucene 7.0 >>>> depends on ICU 59.1, not 56.1 since >>>> https://issues.apache.org/jira/browse/LUCENE-7540 >>>> <https://issues.apache.org/jira/browse/LUCENE-7540>. >>>> >>>> Le ven. 25 août 2017 à 23:42, Anshum Gupta <ansh...@apple.com >>>> <mailto:ansh...@apple.com>> a écrit : >>>> A quick question, in case someone has an idea around what’s going on. When >>>> I run the following command: >>>> >>>> python3 -u dev-tools/scripts/buildAndPushRelease.py --push-local >>>> /Users/anshum/solr/release/7.0.0/rc0 --rc-num 1 --sign <my-key> >>>> >>>> I end up with the following error: >>>> >>>> BUILD FAILED >>>> /Users/anshum/workspace/lucene-solr/build.xml:117: The following error >>>> occurred while executing this line: >>>> /Users/anshum/workspace/lucene-solr/lucene/build.xml:90: The following >>>> error occurred while executing this line: >>>> /Users/anshum/workspace/lucene-solr/lucene/tools/custom-tasks.xml:62: JAR >>>> resource does not exist: analysis/icu/lib/icu4j-56.1.jar >>>> >>>> Any idea as to what’s going on? This generally fails after the tests have >>>> run, and the script has processed for about 45 minutes and it’s consistent >>>> i.e. all the times when the tests pass, the process fails with this >>>> warning. >>>> >>>> I can also confirm that this file exists at >>>> lucene/analysis/icy/lib/icu4j-56.1.jar . >>>> >>>> Has anyone else seen this when working on the release? >>>> >>>> -Anshum >>>> >>>> >>>> >>>>> On Aug 23, 2017, at 4:21 AM, Andrzej Białecki >>>>> <andrzej.biale...@lucidworks.com >>>>> <mailto:andrzej.biale...@lucidworks.com>> wrote: >>>>> >>>>> >>>>>> On 23 Aug 2017, at 13:06, Uwe Schindler <u...@thetaphi.de >>>>>> <mailto:u...@thetaphi.de>> wrote: >>>>>> >>>>>> Keep in mind that there is also branch_7_0. >>>>> >>>>> Right, but the changes related to these issues were committed to master >>>>> before branch_7_0 was created, and these specific issues are only about >>>>> back-porting to 6x. >>>>> >>>>>> >>>>>> Uww >>>>>> >>>>>> Am 23. August 2017 12:26:42 MESZ schrieb "Andrzej Białecki" >>>>>> <a...@getopt.org <mailto:a...@getopt.org>>: >>>>>> >>>>>>> On 23 Aug 2017, at 08:15, Anshum Gupta <ansh...@apple.com >>>>>>> <mailto:ansh...@apple.com>> wrote: >>>>>>> >>>>>>> I also found more issues when comparing 7x, with 6x this time. I’ll >>>>>>> take a look at wether it’s just the CHANGES entries or have these >>>>>>> actually missed the branch. I assume it’s just the CHANGES, but want to >>>>>>> be sure. If the committers involved can pitch in, I’d appreciate, else >>>>>>> I’ll work on this for a bit right now and continue with this tomorrow >>>>>>> morning. >>>>>>> >>>>>>> - SOLR-10477 (Ab) >>>>>> >>>>>> This is a partial back-port of relevant improvements from master to 6x, >>>>>> so there are no strictly corresponding commits on 7x/master. >>>>>> >>>>>>> - SOLR-10631: Metric reporters leak on 6x. (Ab) >>>>>> >>>>>> This one has been fixed as part of other related issues in branches 7.x >>>>>> / master, so it only required a specific fix for 6x. >>>>>> >>>>>>> - SOLR-10000 (Ab) >>>>>>> >>>>>> >>>>>> This has been committed first to 7x, then to 6x and it’s present in >>>>>> branch_6_6. >>>>>> >>>>>> >>>>>> --- >>>>>> Best regards, >>>>>> >>>>>> Andrzej Bialecki >>>>>> >>>>>> >>>>>> -- >>>>>> Uwe Schindler >>>>>> Achterdiek 19, 28357 Bremen >>>>>> https://www.thetaphi.de <https://www.thetaphi.de/> >>>> >>> >> > > >
