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
