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
