> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > >>>> 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 <[email protected]> > >>>>> 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 <[email protected]> > >>>>>> 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 > >>>>>>> <[email protected]> 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: [email protected] > >>>> > >>>> > >>>>>>>> For additional commands, e-mail: [email protected] > >>>> > >>>> > >>>>>>>> > >>>> > >>>> > >>>>>> > >>>> > >>>> > >>>>>> > >>>> > >>>> > >>>>>> -- > >>>> > >>>> > >>>>>> Anshum Gupta > >>>> > >>>> > >>>>> > >>>> > >>>> > >>>>> --------------------------------------------------------------------- > >>>> > >>>> > >>>>> To unsubscribe, e-mail: [email protected] > >>>> > >>>> > >>>>> For additional commands, e-mail: [email protected] > >>>> > >>>> > >>>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> > >>>> > >>>> Regards, > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Atri > >>>> > >>>> > >>>> Apache Concerted > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> --------------------------------------------------------------------- > >>>> > >>>> > >>>> To unsubscribe, e-mail: [email protected] > >>>> > >>>> > >>>> For additional commands, e-mail: [email protected] > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >>> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
