The traditional (non-docker) part of the release should now be wrapped
up. Thanks everyone for the help and answering my questions here and
in Slack. One final question:
The final releaseWizard.py step instructs:
"The Solr WIKI has a page for every version which is often linked to
from WIKI pages to indicate differences between versions, example:
http://wiki.apache.org/solr/Solr4.3. Do the following: Update the page
for the released version with release date and link to release
statement. Create a new placeholder page for the "next" version, if it
does not exist"
But looking at our wiki, the latest of these pages is 8.2
(https://cwiki.apache.org/confluence/display/SOLR/Solr8.2). I've
created the pages as instructed for now. But if we're not following
this step regularly and it hasn't caused any issues maybe we should
remove it from the release process altogether?
Jason
On Thu, Oct 8, 2020 at 5:16 PM David Smiley <dsmiley@apache.org> wrote:
>
> The way GitHub works for contributors is that you are expected to fork a repo and then push to your fork. At that point when you go to the PR area, you'll see a convenient yellow dialog to create a PR based on your pushed branch.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Thu, Oct 8, 2020 at 10:20 AM Chris Hostetter <hossman_lucene@fucit.org> wrote:
>>
>>
>> FWIW: I followed the docs to update the Dockerfiles + TAGS for 8.6.3, and
>> run tests; but since it's in a distinct github repo I don't think i can
>> push to it?
>>
>> so i creaed a GH issue w/patch...
>>
>> https://github.com/docker-solr/docker-solr/issues/349
>>
>>
>>
>> : Date: Tue, 6 Oct 2020 11:33:15 -0400
>> : From: Houston Putman <houstonputman@gmail.com>
>> : Reply-To: dev@lucene.apache.org
>> : To: Solr/Lucene Dev <dev@lucene.apache.org>
>> : Subject: Re: 8.6.3 Release
>> :
>> : That is correct. 8.x docker builds have not been affected in any way.
>> :
>> : On Tue, Oct 6, 2020 at 11:30 AM Cassandra Targett <casstargett@gmail.com>
>> : wrote:
>> :
>> : > I wanted to ask now that the 8.6.3 vote is underway - for the docker-solr
>> : > image, are the update instructions in the docker-solr repo still the same
>> : > for 8.x even though the build process has been moved to the main project
>> : > for 9.0? Meaning, to release the 8.6.3 image there’s no change from before,
>> : > right?
>> : >
>> : > I’m asking specifically about these instructions:
>> : >
>> : > https://github.com/docker-solr/docker-solr/blob/master/update.md
>> : > On Oct 1, 2020, 9:28 AM -0500, Jason Gerlowski <gerlowskija@gmail.com>,
>> : > wrote:
>> : >
>> : > I've put together draft Release Notes for 8.6.3 here. [1] [2]. Can
>> : > someone please sanity check the summaries there when they get a
>> : > chance? Would appreciate the review.
>> : >
>> : > 8.6.3 is a bit interesting in that Lucene has no changes in this
>> : > bugfix release. As a result I had to omit the standard phrase in the
>> : > Solr release notes about there being additional changes at the Lucene
>> : > level, and change some of the wording in the Lucene announcement to
>> : > indicate the lack of changes. So that's something to pay particular
>> : > attention to, if someone can check my wording there.
>> : >
>> : > [1] https://cwiki.apache.org/confluence/display/SOLR/DRAFT-ReleaseNote863
>> : > [2]
>> : > https://cwiki.apache.org/confluence/display/LUCENE/DRAFT-ReleaseNote863
>> : >
>> : > On Wed, Sep 30, 2020 at 10:57 AM Jason Gerlowski <gerlowskija@gmail.com>
>> : > wrote:
>> : >
>> : >
>> : > The only one that was previously mentioned as a blocker was
>> : > SOLR-14835, but from the comments on the ticket it looks like it ended
>> : > up being purely a cosmetic issue. Andrzej left a comment there
>> : > suggesting that we "address" this with documentation for 8.6.3 but
>> : > otherwise leave it as-is.
>> : >
>> : > So it looks like we're unblocked on starting the release process.
>> : > Will begin the preliminary steps this afternoon.
>> : >
>> : > On Tue, Sep 29, 2020 at 3:40 PM Cassandra Targett <casstargett@gmail.com>
>> : > wrote:
>> : >
>> : >
>> : > It looks to me like everything for 8.6.3 is resolved now (
>> : > https://issues.apache.org/jira/projects/SOLR/versions/12348713), and it
>> : > seems from comments in SOLR-14897 and SOLR-14898 that those fixes make a
>> : > Jetty upgrade less compelling to try.
>> : >
>> : > Are there any other issues not currently marked for 8.6.3 we’re waiting
>> : > for before starting the RC?
>> : > On Sep 29, 2020, 12:04 PM -0500, Jason Gerlowski <gerlowskija@gmail.com>,
>> : > wrote:
>> : >
>> : > That said, if someone can use 8.6.3, what’s stopping them from going to
>> : > 8.7 when it’e released?
>> : >
>> : >
>> : > The same things that always stop users from going directly to the
>> : > latest-and-greatest: fear of instability from new minor-release
>> : > features, reliance on behavior changed across minor versions, breaking
>> : > changes on Lucene elements that don't guarantee backcompat (e.g.
>> : > SOLR-14254), security issues in later versions (new libraries pulled
>> : > in with vulns), etc. There's lots of reasons a given user might want
>> : > to stick on 8.6.x rather than 8.7 (in the short/medium term).
>> : >
>> : > I'm ambivalent to whether we upgrade Jetty in 8.6.3 - as I said above
>> : > the worst of the Jetty issue should be mitigated by work on our end -
>> : > but I think there's a lot of reasons users might not upgrade as far as
>> : > we'd expect/like.
>> : >
>> : >
>> : > On Mon, Sep 28, 2020 at 2:05 PM Erick Erickson <erickerickson@gmail.com>
>> : > wrote:
>> : >
>> : >
>> : > For me, there’s a sharp distinction between changing a dependency in a
>> : > point release just because there’s a new version, and changing the
>> : > dependency because there’s a bug in it. That said, if someone can use
>> : > 8.6.3, what’s stopping them from going to 8.7 when it’e released? Would it
>> : > make more sense to do the upgrades for 8.7 and get that out the door rather
>> : > than backport?
>> : >
>> : > FWIW,
>> : > Erick
>> : >
>> : > On Sep 28, 2020, at 1:45 PM, Jason Gerlowski <gerlowskija@gmail.com>
>> : > wrote:
>> : >
>> : > Hey all,
>> : >
>> : > I wanted to add 2 more blocker tickets to the list: SOLR-14897 and
>> : > SOLR-14898. These tickets (while bad bugs in their own right) are
>> : > especially necessary because they work around a Jetty buffer-reuse bug
>> : > (see SOLR-14896) that causes sporadic request failures once triggered.
>> : >
>> : > So that brings the list of 8.6.3 blockers up to: SOLR-14850,
>> : > SOLR-14835, SOLR-14897, and SOLR-14898. (Thanks David for the quick
>> : > work on SOLR-14768!)
>> : >
>> : > Additionally, should we also consider a Jetty upgrade for 8.6.3 in
>> : > light of the issue mentioned above? I know it's atypical for bug-fix
>> : > releases to change deps, but here the bug is serious and tied directly
>> : > to the dep. SOLR-14897 and SOLR-14898 help greatly here, but the
>> : > Jetty bug is likely still a problem for users making requests that
>> : > match a specific (albeit rare) profile. Anyone have thoughts?
>> : >
>> : > Best,
>> : >
>> : > Jason
>> : >
>> : > On Fri, Sep 25, 2020 at 12:28 AM Houston Putman <houstonputman@gmail.com>
>> : > wrote:
>> : >
>> : >
>> : > If I recall correctly, thats a step in the release wizard.
>> : >
>> : > After checking, I think this fits the bill:
>> : >
>> : > https://github.com/apache/lucene-solr/blob/master/dev-tools/scripts/releaseWizard.yaml#L1435
>> : >
>> : > - Houston
>> : >
>> : > On Fri, Sep 25, 2020 at 12:06 AM David Smiley <dsmiley@apache.org> wrote:
>> : >
>> : >
>> : > When moving changes from 8.7 to 8.6.3, must we (the mover of an individual
>> : > change) move the CHANGES.txt entry on all branches -- master, branch_8x,
>> : > branch_8_6? I expect the release branch but am unsure of the other two. In
>> : > the past I have but it's annoying. Does the RM sync CHANGES.txt on the
>> : > other branches in one go? If not, I think it'd make sense for that to
>> : > happen.
>> : >
>> : > ~ David Smiley
>> : > Apache Lucene/Solr Search Developer
>> : > http://www.linkedin.com/in/davidwsmiley
>> : >
>> : >
>> : > On Thu, Sep 24, 2020 at 6:22 AM Atri Sharma <atri@apache.org> wrote:
>> : >
>> : >
>> : > I will push the 8.7 release by a week to give Jason enough headroom to
>> : >
>> : >
>> : > do the 8.6.3 release.
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > Jason, let me know if you need me to assist on the 8.6.3 release.
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > On Thu, Sep 24, 2020 at 3:23 PM Jason Gerlowski <gerlowskija@gmail.com>
>> : > wrote:
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > OK, in that case I'll try my best to keep the 8.6.3 process moving
>> : >
>> : >
>> : >
>> : > then, so Atri can stick as close to his proposed schedule as possible.
>> : >
>> : >
>> : >
>> : > My apologies - I didn't realize I'd be putting the brakes on 8.7 by
>> : >
>> : >
>> : >
>> : > proposing a bug-fix release. But the reasons make sense given what
>> : >
>> : >
>> : >
>> : > others mentioned above.
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > As branch_8_6 should be pretty stable by now I wonder if we really need to
>> : > wait one week?
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > There's no special reason on my end. I suggested a week to give
>> : >
>> : >
>> : >
>> : > others time to backport anything they wanted included, but I'm happy
>> : >
>> : >
>> : >
>> : > to start the process as soon as all the expected changes land.
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > Best,
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > Jason
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > On Thu, Sep 24, 2020 at 1:48 AM Anshum Gupta <anshum@anshumgupta.net>
>> : > wrote:
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > Simultaneous releases are also confusing for users, in addition to the
>> : > back-compat tests as our website chronologically lists our releases and it
>> : > gets complicated for someone reading the 'News' page.
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > As 8.7 isn't a release that needs to be rushed, waiting until 8.6.3 is
>> : > released and back-compat indexes are pushed will make things easier for the
>> : > RMs and community.
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > On Wed, Sep 23, 2020 at 1:43 PM David Smiley <dsmiley@apache.org> wrote:
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > Jason: Thanks for volunteering to do an 8.6.3! I recently fixed
>> : > SOLR-14768, multipart HTTP POST was broken in 8.6 (a regression I
>> : > introduced). If you can't do the release or need help, I will take over.
>> : > It's the least I can offer in repentance for the regression.
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > ~ David Smiley
>> : >
>> : >
>> : >
>> : > Apache Lucene/Solr Search Developer
>> : >
>> : >
>> : >
>> : > http://www.linkedin.com/in/davidwsmiley
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > On Wed, Sep 23, 2020 at 10:07 AM Jason Gerlowski <gerlowskija@gmail.com>
>> : > wrote:
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > Hi all,
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > I ran into a query-parsing bug recently in SOLR-14859 that caused
>> : >
>> : >
>> : >
>> : > problems for some of my usecases. I wanted to volunteer as RM for an
>> : >
>> : >
>> : >
>> : > 8.6.3 to get a bugfix release out for users that aren't ready for some
>> : >
>> : >
>> : >
>> : > of the bigger changes in 8.7
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > I was thinking of cutting the branch in a week's time to give others a
>> : >
>> : >
>> : >
>> : > chance to backport any bug-fixes they might want included, with an RC
>> : >
>> : >
>> : >
>> : > to follow shortly. Does anyone have any concerns with that plan, or
>> : >
>> : >
>> : >
>> : > have anything they'd like to fix or backport before an 8.6.3 goes out?
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > Best,
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > Jason
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > ---------------------------------------------------------------------
>> : >
>> : >
>> : >
>> : > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> : >
>> : >
>> : >
>> : > For additional commands, e-mail: dev-help@lucene.apache.org
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > --
>> : >
>> : >
>> : >
>> : > Anshum Gupta
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > ---------------------------------------------------------------------
>> : >
>> : >
>> : >
>> : > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> : >
>> : >
>> : >
>> : > For additional commands, e-mail: dev-help@lucene.apache.org
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > --
>> : >
>> : >
>> : > Regards,
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > Atri
>> : >
>> : >
>> : > Apache Concerted
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > ---------------------------------------------------------------------
>> : >
>> : >
>> : > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> : >
>> : >
>> : > For additional commands, e-mail: dev-help@lucene.apache.org
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > ---------------------------------------------------------------------
>> : > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> : > For additional commands, e-mail: dev-help@lucene.apache.org
>> : >
>> : >
>> : >
>> : > ---------------------------------------------------------------------
>> : > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> : > For additional commands, e-mail: dev-help@lucene.apache.org
>> : >
>> : >
>> : > ---------------------------------------------------------------------
>> : > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> : > For additional commands, e-mail: dev-help@lucene.apache.org
>> : >
>> : >
>> : > ---------------------------------------------------------------------
>> : > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> : > For additional commands, e-mail: dev-help@lucene.apache.org
>> : >
>> : >
>> :
>>
>> -Hoss
>> http://www.lucidworks.com/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
up. Thanks everyone for the help and answering my questions here and
in Slack. One final question:
The final releaseWizard.py step instructs:
"The Solr WIKI has a page for every version which is often linked to
from WIKI pages to indicate differences between versions, example:
http://wiki.apache.org/solr/Solr4.3. Do the following: Update the page
for the released version with release date and link to release
statement. Create a new placeholder page for the "next" version, if it
does not exist"
But looking at our wiki, the latest of these pages is 8.2
(https://cwiki.apache.org/confluence/display/SOLR/Solr8.2). I've
created the pages as instructed for now. But if we're not following
this step regularly and it hasn't caused any issues maybe we should
remove it from the release process altogether?
Jason
On Thu, Oct 8, 2020 at 5:16 PM David Smiley <dsmiley@apache.org> wrote:
>
> The way GitHub works for contributors is that you are expected to fork a repo and then push to your fork. At that point when you go to the PR area, you'll see a convenient yellow dialog to create a PR based on your pushed branch.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Thu, Oct 8, 2020 at 10:20 AM Chris Hostetter <hossman_lucene@fucit.org> wrote:
>>
>>
>> FWIW: I followed the docs to update the Dockerfiles + TAGS for 8.6.3, and
>> run tests; but since it's in a distinct github repo I don't think i can
>> push to it?
>>
>> so i creaed a GH issue w/patch...
>>
>> https://github.com/docker-solr/docker-solr/issues/349
>>
>>
>>
>> : Date: Tue, 6 Oct 2020 11:33:15 -0400
>> : From: Houston Putman <houstonputman@gmail.com>
>> : Reply-To: dev@lucene.apache.org
>> : To: Solr/Lucene Dev <dev@lucene.apache.org>
>> : Subject: Re: 8.6.3 Release
>> :
>> : That is correct. 8.x docker builds have not been affected in any way.
>> :
>> : On Tue, Oct 6, 2020 at 11:30 AM Cassandra Targett <casstargett@gmail.com>
>> : wrote:
>> :
>> : > I wanted to ask now that the 8.6.3 vote is underway - for the docker-solr
>> : > image, are the update instructions in the docker-solr repo still the same
>> : > for 8.x even though the build process has been moved to the main project
>> : > for 9.0? Meaning, to release the 8.6.3 image there’s no change from before,
>> : > right?
>> : >
>> : > I’m asking specifically about these instructions:
>> : >
>> : > https://github.com/docker-solr/docker-solr/blob/master/update.md
>> : > On Oct 1, 2020, 9:28 AM -0500, Jason Gerlowski <gerlowskija@gmail.com>,
>> : > wrote:
>> : >
>> : > I've put together draft Release Notes for 8.6.3 here. [1] [2]. Can
>> : > someone please sanity check the summaries there when they get a
>> : > chance? Would appreciate the review.
>> : >
>> : > 8.6.3 is a bit interesting in that Lucene has no changes in this
>> : > bugfix release. As a result I had to omit the standard phrase in the
>> : > Solr release notes about there being additional changes at the Lucene
>> : > level, and change some of the wording in the Lucene announcement to
>> : > indicate the lack of changes. So that's something to pay particular
>> : > attention to, if someone can check my wording there.
>> : >
>> : > [1] https://cwiki.apache.org/confluence/display/SOLR/DRAFT-ReleaseNote863
>> : > [2]
>> : > https://cwiki.apache.org/confluence/display/LUCENE/DRAFT-ReleaseNote863
>> : >
>> : > On Wed, Sep 30, 2020 at 10:57 AM Jason Gerlowski <gerlowskija@gmail.com>
>> : > wrote:
>> : >
>> : >
>> : > The only one that was previously mentioned as a blocker was
>> : > SOLR-14835, but from the comments on the ticket it looks like it ended
>> : > up being purely a cosmetic issue. Andrzej left a comment there
>> : > suggesting that we "address" this with documentation for 8.6.3 but
>> : > otherwise leave it as-is.
>> : >
>> : > So it looks like we're unblocked on starting the release process.
>> : > Will begin the preliminary steps this afternoon.
>> : >
>> : > On Tue, Sep 29, 2020 at 3:40 PM Cassandra Targett <casstargett@gmail.com>
>> : > wrote:
>> : >
>> : >
>> : > It looks to me like everything for 8.6.3 is resolved now (
>> : > https://issues.apache.org/jira/projects/SOLR/versions/12348713), and it
>> : > seems from comments in SOLR-14897 and SOLR-14898 that those fixes make a
>> : > Jetty upgrade less compelling to try.
>> : >
>> : > Are there any other issues not currently marked for 8.6.3 we’re waiting
>> : > for before starting the RC?
>> : > On Sep 29, 2020, 12:04 PM -0500, Jason Gerlowski <gerlowskija@gmail.com>,
>> : > wrote:
>> : >
>> : > That said, if someone can use 8.6.3, what’s stopping them from going to
>> : > 8.7 when it’e released?
>> : >
>> : >
>> : > The same things that always stop users from going directly to the
>> : > latest-and-greatest: fear of instability from new minor-release
>> : > features, reliance on behavior changed across minor versions, breaking
>> : > changes on Lucene elements that don't guarantee backcompat (e.g.
>> : > SOLR-14254), security issues in later versions (new libraries pulled
>> : > in with vulns), etc. There's lots of reasons a given user might want
>> : > to stick on 8.6.x rather than 8.7 (in the short/medium term).
>> : >
>> : > I'm ambivalent to whether we upgrade Jetty in 8.6.3 - as I said above
>> : > the worst of the Jetty issue should be mitigated by work on our end -
>> : > but I think there's a lot of reasons users might not upgrade as far as
>> : > we'd expect/like.
>> : >
>> : >
>> : > On Mon, Sep 28, 2020 at 2:05 PM Erick Erickson <erickerickson@gmail.com>
>> : > wrote:
>> : >
>> : >
>> : > For me, there’s a sharp distinction between changing a dependency in a
>> : > point release just because there’s a new version, and changing the
>> : > dependency because there’s a bug in it. That said, if someone can use
>> : > 8.6.3, what’s stopping them from going to 8.7 when it’e released? Would it
>> : > make more sense to do the upgrades for 8.7 and get that out the door rather
>> : > than backport?
>> : >
>> : > FWIW,
>> : > Erick
>> : >
>> : > On Sep 28, 2020, at 1:45 PM, Jason Gerlowski <gerlowskija@gmail.com>
>> : > wrote:
>> : >
>> : > Hey all,
>> : >
>> : > I wanted to add 2 more blocker tickets to the list: SOLR-14897 and
>> : > SOLR-14898. These tickets (while bad bugs in their own right) are
>> : > especially necessary because they work around a Jetty buffer-reuse bug
>> : > (see SOLR-14896) that causes sporadic request failures once triggered.
>> : >
>> : > So that brings the list of 8.6.3 blockers up to: SOLR-14850,
>> : > SOLR-14835, SOLR-14897, and SOLR-14898. (Thanks David for the quick
>> : > work on SOLR-14768!)
>> : >
>> : > Additionally, should we also consider a Jetty upgrade for 8.6.3 in
>> : > light of the issue mentioned above? I know it's atypical for bug-fix
>> : > releases to change deps, but here the bug is serious and tied directly
>> : > to the dep. SOLR-14897 and SOLR-14898 help greatly here, but the
>> : > Jetty bug is likely still a problem for users making requests that
>> : > match a specific (albeit rare) profile. Anyone have thoughts?
>> : >
>> : > Best,
>> : >
>> : > Jason
>> : >
>> : > On Fri, Sep 25, 2020 at 12:28 AM Houston Putman <houstonputman@gmail.com>
>> : > wrote:
>> : >
>> : >
>> : > If I recall correctly, thats a step in the release wizard.
>> : >
>> : > After checking, I think this fits the bill:
>> : >
>> : > https://github.com/apache/lucene-solr/blob/master/dev-tools/scripts/releaseWizard.yaml#L1435
>> : >
>> : > - Houston
>> : >
>> : > On Fri, Sep 25, 2020 at 12:06 AM David Smiley <dsmiley@apache.org> wrote:
>> : >
>> : >
>> : > When moving changes from 8.7 to 8.6.3, must we (the mover of an individual
>> : > change) move the CHANGES.txt entry on all branches -- master, branch_8x,
>> : > branch_8_6? I expect the release branch but am unsure of the other two. In
>> : > the past I have but it's annoying. Does the RM sync CHANGES.txt on the
>> : > other branches in one go? If not, I think it'd make sense for that to
>> : > happen.
>> : >
>> : > ~ David Smiley
>> : > Apache Lucene/Solr Search Developer
>> : > http://www.linkedin.com/in/davidwsmiley
>> : >
>> : >
>> : > On Thu, Sep 24, 2020 at 6:22 AM Atri Sharma <atri@apache.org> wrote:
>> : >
>> : >
>> : > I will push the 8.7 release by a week to give Jason enough headroom to
>> : >
>> : >
>> : > do the 8.6.3 release.
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > Jason, let me know if you need me to assist on the 8.6.3 release.
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > On Thu, Sep 24, 2020 at 3:23 PM Jason Gerlowski <gerlowskija@gmail.com>
>> : > wrote:
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > OK, in that case I'll try my best to keep the 8.6.3 process moving
>> : >
>> : >
>> : >
>> : > then, so Atri can stick as close to his proposed schedule as possible.
>> : >
>> : >
>> : >
>> : > My apologies - I didn't realize I'd be putting the brakes on 8.7 by
>> : >
>> : >
>> : >
>> : > proposing a bug-fix release. But the reasons make sense given what
>> : >
>> : >
>> : >
>> : > others mentioned above.
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > As branch_8_6 should be pretty stable by now I wonder if we really need to
>> : > wait one week?
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > There's no special reason on my end. I suggested a week to give
>> : >
>> : >
>> : >
>> : > others time to backport anything they wanted included, but I'm happy
>> : >
>> : >
>> : >
>> : > to start the process as soon as all the expected changes land.
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > Best,
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > Jason
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > On Thu, Sep 24, 2020 at 1:48 AM Anshum Gupta <anshum@anshumgupta.net>
>> : > wrote:
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > Simultaneous releases are also confusing for users, in addition to the
>> : > back-compat tests as our website chronologically lists our releases and it
>> : > gets complicated for someone reading the 'News' page.
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > As 8.7 isn't a release that needs to be rushed, waiting until 8.6.3 is
>> : > released and back-compat indexes are pushed will make things easier for the
>> : > RMs and community.
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > On Wed, Sep 23, 2020 at 1:43 PM David Smiley <dsmiley@apache.org> wrote:
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > Jason: Thanks for volunteering to do an 8.6.3! I recently fixed
>> : > SOLR-14768, multipart HTTP POST was broken in 8.6 (a regression I
>> : > introduced). If you can't do the release or need help, I will take over.
>> : > It's the least I can offer in repentance for the regression.
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > ~ David Smiley
>> : >
>> : >
>> : >
>> : > Apache Lucene/Solr Search Developer
>> : >
>> : >
>> : >
>> : > http://www.linkedin.com/in/davidwsmiley
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > On Wed, Sep 23, 2020 at 10:07 AM Jason Gerlowski <gerlowskija@gmail.com>
>> : > wrote:
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > Hi all,
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > I ran into a query-parsing bug recently in SOLR-14859 that caused
>> : >
>> : >
>> : >
>> : > problems for some of my usecases. I wanted to volunteer as RM for an
>> : >
>> : >
>> : >
>> : > 8.6.3 to get a bugfix release out for users that aren't ready for some
>> : >
>> : >
>> : >
>> : > of the bigger changes in 8.7
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > I was thinking of cutting the branch in a week's time to give others a
>> : >
>> : >
>> : >
>> : > chance to backport any bug-fixes they might want included, with an RC
>> : >
>> : >
>> : >
>> : > to follow shortly. Does anyone have any concerns with that plan, or
>> : >
>> : >
>> : >
>> : > have anything they'd like to fix or backport before an 8.6.3 goes out?
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > Best,
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > Jason
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > ---------------------------------------------------------------------
>> : >
>> : >
>> : >
>> : > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> : >
>> : >
>> : >
>> : > For additional commands, e-mail: dev-help@lucene.apache.org
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > --
>> : >
>> : >
>> : >
>> : > Anshum Gupta
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > ---------------------------------------------------------------------
>> : >
>> : >
>> : >
>> : > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> : >
>> : >
>> : >
>> : > For additional commands, e-mail: dev-help@lucene.apache.org
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > --
>> : >
>> : >
>> : > Regards,
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > Atri
>> : >
>> : >
>> : > Apache Concerted
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > ---------------------------------------------------------------------
>> : >
>> : >
>> : > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> : >
>> : >
>> : > For additional commands, e-mail: dev-help@lucene.apache.org
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : >
>> : > ---------------------------------------------------------------------
>> : > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> : > For additional commands, e-mail: dev-help@lucene.apache.org
>> : >
>> : >
>> : >
>> : > ---------------------------------------------------------------------
>> : > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> : > For additional commands, e-mail: dev-help@lucene.apache.org
>> : >
>> : >
>> : > ---------------------------------------------------------------------
>> : > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> : > For additional commands, e-mail: dev-help@lucene.apache.org
>> : >
>> : >
>> : > ---------------------------------------------------------------------
>> : > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> : > For additional commands, e-mail: dev-help@lucene.apache.org
>> : >
>> : >
>> :
>>
>> -Hoss
>> http://www.lucidworks.com/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org