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
