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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >> 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 <[email protected]> >> 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 <[email protected]> >> 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 <[email protected]> >> 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 <[email protected]> >> wrote: >> > On Thu, Apr 28, 2016 at 12:04 PM, Anshum Gupta <[email protected]> >> 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: [email protected] >> > For additional commands, e-mail: [email protected] >> > >> > >> > >> > >> > -- >> > Anshum Gupta >> > >> > >> > >> > -- >> > Anshum Gupta >> > >> > >> > >> > -- >> > Anshum Gupta >> > >> > >> > >> > -- >> > Anshum Gupta >> > >> > >> > >> > -- >> > Anshum Gupta >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > -- > Anshum Gupta > -- Anshum Gupta
