I tried to add the back compat index for 5.5.0 by running the script on branch_5x, but it errors out when running the test with : "Extra back-compat test files: 5.5.0-cfs". I'm confused here in terms of what the instructions say and what's supposed to be done.
On Fri, Apr 29, 2016 at 6:52 PM, Anshum Gupta <ans...@anshumgupta.net> wrote: > Seems like 5.5.0 back compat index was never added. Can someone confirm > that? > I have the RC but the smoke test failed when I ran it locally. Here's the > error: > > Verify... > confirm all releases have coverage in TestBackwardsCompatibility > find all past Lucene releases... > run TestBackwardsCompatibility.. > Backcompat testing not required for release 6.0.0 because it's not > less than 5.5.1 > Releases that don't seem to be tested: > 5.5.0 > Traceback (most recent call last): > File "dev-tools/scripts/smokeTestRelease.py", line 1443, in <module> > main() > File "dev-tools/scripts/smokeTestRelease.py", line 1387, in main > smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, > c.is_signed, ' '.join(c.test_args)) > File "dev-tools/scripts/smokeTestRelease.py", line 1425, in smokeTest > unpackAndVerify(java, 'lucene', tmpDir, 'lucene-%s-src.tgz' % version, > gitRevision, version, testArgs, baseURL) > File "dev-tools/scripts/smokeTestRelease.py", line 589, in > unpackAndVerify > verifyUnpacked(java, project, artifact, unpackPath, gitRevision, > version, testArgs, tmpDir, baseURL) > File "dev-tools/scripts/smokeTestRelease.py", line 769, in verifyUnpacked > confirmAllReleasesAreTestedForBackCompat(version, unpackPath) > File "dev-tools/scripts/smokeTestRelease.py", line 1380, in > confirmAllReleasesAreTestedForBackCompat > raise RuntimeError('some releases are not tested by > TestBackwardsCompatibility?') > RuntimeError: some releases are not tested by TestBackwardsCompatibility? > > > > On Fri, Apr 29, 2016 at 11:05 AM, Anshum Gupta <ans...@anshumgupta.net> > wrote: > >> Something seems to be going on with TestManagedSchemaAPI as it's been >> consistently failing. >> I woke up with a fever today so I'll try and debug it some time later if >> I'm unable to get an RC built, but if I do get the RC, I'll get it out to >> vote and in parallel see if it's something that needs fixing unless someone >> else beats me to it. >> >> On Fri, Apr 29, 2016 at 9:26 AM, Anshum Gupta <ans...@anshumgupta.net> >> wrote: >> >>> That makes sense considering there are those checks for ignoring 1 >>> missing version. >>> >>> On Fri, Apr 29, 2016 at 6:53 AM, Steve Rowe <sar...@gmail.com> wrote: >>> >>>> Anshum, >>>> >>>> TL;DR: When there is only one release in flight, I think it’s okay to >>>> run addVersion.py on all branches at the start of the release process for >>>> all types of releases. >>>> >>>> When we chatted last night I said backcompat index testing was a >>>> problem on non-release branches in the interval between adding a >>>> not-yet-released version to o.a.l.util.Version and when a backcompat index >>>> is committed on the branch. I was wrong. >>>> >>>> Here are the places where there are back-compat coverage tests: >>>> >>>> 1. smokeTestRelease.py's confirmAllReleasesAreTestedForBackCompat() >>>> will succeed until release artifacts have been published - see >>>> getAllLuceneReleases() for where they are scraped off the lucene release >>>> list page on archive.apache.org. So back-compat indexes should be >>>> generated and committed as soon as possible after publishing artifacts. >>>> >>>> 2. backward-codec’s TestBackwardsCompatibility.testAllVersionsTested() >>>> will still succeed if a single version is not tested. Here’s the code: >>>> >>>> // we could be missing up to 1 file, which may be due to a release >>>> that is in progress >>>> if (missingFiles.size() <= 1 && extraFiles.isEmpty()) { >>>> >>>> The above test could be improved by checking for the presence of >>>> published release artifacts for each release like smokeTestRelease.py does, >>>> and then not requiring the backcompat index be present for those that are >>>> not yet published; this would allow for multiple in-flight releases. >>>> >>>> Steve >>>> >>>> > On Apr 28, 2016, at 10:44 PM, Anshum Gupta <ans...@anshumgupta.net> >>>> wrote: >>>> > >>>> > I've updated the "Update Version Numbers in the Source Code" section >>>> on the ReleaseToDo page. It'd be good to have some one else also take a >>>> look at it. >>>> > >>>> > Here is what I've changed (only bug fix release): >>>> > * Only bump up the version on the release branch using addVersion.py >>>> > * Don't bump it up on the non-release versions in case of bug fix >>>> release. >>>> > * As part of the post-release process, use the commit hash from the >>>> release branch version bump up, to increment the version on the non-release >>>> branches. >>>> > >>>> > I thought we could do this for non bug-fix releases too, but I was >>>> wrong. Minor versions need to be bumped up on stable branches (and trunk) >>>> because during the release process for say version 6.1, there might be >>>> commits for 6.2 and we'd need stable branches and master, both to support >>>> those commits. >>>> > We could debate about not needing something like this for major >>>> versions but then I don't think it's worth the pain of different release >>>> processes for each branch but I'm not stuck up with this. >>>> > >>>> > >>>> > On Thu, Apr 28, 2016 at 5:31 PM, Anshum Gupta <ans...@anshumgupta.net> >>>> wrote: >>>> > That's fixed (about to commit the fix from LUCENE-7265) thought. >>>> > >>>> > While discussing the release process, Steve mentioned that we should >>>> document the failing back-compat index test on the non-release branches due >>>> to the missing index for the unreleased version. >>>> > On discussing further, he suggested that we instead move the process >>>> of adding the version to non-release branches as a post-release task. This >>>> way, we wouldn't have failing tests until the release goes through and the >>>> back-compat indexes are checked in. >>>> > >>>> > We still would have failing tests for the release branch but there's >>>> no way around that. >>>> > >>>> > So, I'll change the documentation to move those steps as post-release >>>> tasks. >>>> > >>>> > >>>> > On Thu, Apr 28, 2016 at 11:40 AM, Anshum Gupta < >>>> ans...@anshumgupta.net> wrote: >>>> > Seems like LUCENE-6938 removed the merge logic that used the change >>>> id. Now the merge doesn't happen, and there's no logic that replaces it. >>>> > >>>> > I certainly can do with some help on this one. >>>> > >>>> > On Thu, Apr 28, 2016 at 11:24 AM, Anshum Gupta < >>>> ans...@anshumgupta.net> wrote: >>>> > Just wanted to make sure I wasn't missing something here again. While >>>> trying to update the version on 5x, after having done that on 5.5, using >>>> the addVersion.py script and following the instructions, the command >>>> consistently fails. Here's what I've been trying to do: >>>> > >>>> > python3 -u dev-tools/scripts/addVersion.py --changeid 49ba147 5.5.1 >>>> > >>>> > Seems like addVersion.py is broken for minor version releases so I'd >>>> need some help with someone who has a better understanding of python than I >>>> do. I observed that 5.5.1 Version gets added to Version.java but also gets >>>> marked as deprecated. >>>> > >>>> > >>>> > >>>> > On Thu, Apr 28, 2016 at 9:27 AM, Anshum Gupta <ans...@anshumgupta.net> >>>> wrote: >>>> > Too much going on! Thanks Yonik. >>>> > I'll start working on the RC now. >>>> > >>>> > NOTE: Please don't back port any more issues right now. In case of >>>> exceptions, please raise them here. >>>> > >>>> > On Thu, Apr 28, 2016 at 9:09 AM, Yonik Seeley <ysee...@gmail.com> >>>> wrote: >>>> > On Thu, Apr 28, 2016 at 12:04 PM, Anshum Gupta < >>>> ans...@anshumgupta.net> wrote: >>>> > > Thanks. I'm waiting for the last back port of SOLR-8865. >>>> > >>>> > It should be already be there... I closed it yesterday. >>>> > -Yonik >>>> > >>>> > --------------------------------------------------------------------- >>>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>>> > For additional commands, e-mail: dev-h...@lucene.apache.org >>>> > >>>> > >>>> > >>>> > >>>> > -- >>>> > Anshum Gupta >>>> > >>>> > >>>> > >>>> > -- >>>> > Anshum Gupta >>>> > >>>> > >>>> > >>>> > -- >>>> > Anshum Gupta >>>> > >>>> > >>>> > >>>> > -- >>>> > Anshum Gupta >>>> > >>>> > >>>> > >>>> > -- >>>> > Anshum Gupta >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>>> For additional commands, e-mail: dev-h...@lucene.apache.org >>>> >>>> >>> >>> >>> -- >>> Anshum Gupta >>> >> >> >> >> -- >> Anshum Gupta >> > > > > -- > Anshum Gupta > -- Anshum Gupta