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
