Since there is no concrete design available for that as of today, that's
why I mentioned about "keeping the door open" for 8.12. I'm not proposing a
8.12 today, nor am I saying 8.12 is needed. But, in case we need one, we
should have the ability to release it. Anyway, this discussion should
rather happen on the Solr list.

On Sat, 20 Nov, 2021, 10:10 pm Timothy Potter, <[email protected]> wrote:

> A Solr 8.12 with Lucene 8.11? Not sure of the details on that but
> sounds like a giant mess waiting to happen (at the very least, would
> require a bunch of complicated changes to the release process). We
> need to stop adding features to 8x and focus on 9. I can foresee an
> 8.11.2 with bug fixes only (8.11.1 is already planned to drop
> soon'ish). Why would Solr need an 8.12? I suspect it's related to
> upgrading plugins, but that's been an open issue for a long while and
> seems to keep getting pushed out. We can't just keep planning new
> feature releases because of this plugin upgrade problem. If we really
> need an 8.12, then we need to see a concrete design on how the upgrade
> process will work in an 8.12. Perhaps there's a better approach that
> only relies on code changes to the 9x line? Tough to say, we have no
> designs or descriptions of the upgrade problem at this point.
>
> As of today, I'd be strongly against a Solr 8.12 release.
>
> Tim
>
> On Sat, Nov 20, 2021 at 8:32 AM Ishan Chattopadhyaya
> <[email protected]> wrote:
> >
> > I think we should keep the door open for a 8.12 release of Solr (based
> on 8.11 Lucene). This might mean some split in the codebase, and this can
> either happen in the lucene-solr repo or the solr repo (I'm okay with
> either).
> >
> > On Sat, Nov 20, 2021 at 7:59 PM Adrien Grand <[email protected]> wrote:
> >>
> >> Uwe brought up the question on a the vote thread: we are not going to
> do a 8.12 release, so what should we do of branch_8x?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

Reply via email to