Hi,

As of today, there are still many open Bug tickets affecting 10.0, which 
presumably should be fixed in 10.1 - or at least they should be evaluated and 
either downgraded or deliberately scheduled for a later release:
* 23 Major
* 6 Critical
* 4 Blocker

Blockers:

* SOLR-18298: ZkController.onReconnect Is Triggered Excessively (PR)
* SOLR-18301: Overseer Election May Not Converge After ZK Disconnect (PR)
* SOLR-18324: V2 (JAX-RS) requests can throw a cascading NPE / RTimer assertion 
failure when a `SolrQueryRequest` isn't attached to the request context (PR)
* SOLR-18278: SOLR JETTY dependency decoupling didn't work properly

All are currently Unassigned in Jira but three of them have PRs. SOLR-18278 
needs to be verified because the description is very sparse.

Critical:

* SOLR-18407: Solr 10 emits duplicate JVM metrics from both 
runtime-telemetry-java8 and runtime-telemetry-java17 scopes on Java 17
* SOLR-18273: Solr 10.0.0 treats short ZooKeeper leader failover as 
session-expiration recovery and removes/re-registers live_nodes
* SOLR-18276: Solr 10.0.0 treats short ZooKeeper leader failover as 
session-expiration recovery and removes/re-registers live_nodes
* SOLR-18275: Solr 10.0.0 treats short ZooKeeper leader failover as 
session-expiration recovery and removes/re-registers live_nodes
* SOLR-18274: Solr 10.0.0 treats short ZooKeeper leader failover as 
session-expiration recovery and removes/re-registers live_nodes
* SOLR-16560: Pull replication appears to consume excessive CPU as it does not 
use Segment Reader pooling

SOLR-18276, SOLR-18275 and SOLR-18274 are duplicates of SOLR-18273 and can be 
closed.

SOLR-18407, 18273, 16560 are all Unassigned, with no PRs.


Any input on this list would be appreciated. Please also take a look at the 
Major tickets, perhaps some of them should be re-evaluated for 10.1, either 
down- or up-graded.

Andrzej



> On 8 Sep 2026, at 17:00, Andrzej Białecki <[email protected]> wrote:
> 
> Fine with me, there are still several tickets in-flight that IMHO should be 
> included in 10.1, so it will take another week or two anyway.
> 
> Andrzej
> 
>> On 8 Sep 2026, at 12:34, Jan Høydahl <[email protected]> wrote:
>> 
>> The no overlap releases has been a self imposed limitation to avoid 
>> confusion, and I guess it is cleaner to have 9.11 changelog in the 10.1 
>> release. During RCs there may also surface need for bugfixes that will 
>> trickle from main, and that could then potentially require re-spin of both 
>> releases.
>> 
>> So if we are to keep with tradition we do 9.x first and then 10.x 
>> immediately after. But technically we could have both in-flight...
>> 
>> Jan
>> 
>>> 7. sep. 2026 kl. 16:30 skrev David Smiley <[email protected]>:
>>> 
>>> I'm not sure what release overlap concerns exist but I thought there was a
>>> limitation on concurrent releases.  Maybe Jan knows.
>>> 
>>> RE 10.1:  There's https://issues.apache.org/jira/browse/SOLR-18130 on 10.x
>>> (not 10.0), which opened up a security concern.  It's not released, so no
>>> reason for me to be too secretative.  I've had the concern on my mental
>>> backlog for months with code done for it for months likewise but
>>> frustratingly it's somewhat blocked by other WIP for a vulnerability that I
>>> don't want to interfere with (i.e. don't want to make backporting harder).
>>> 
>>> On Thu, Sep 3, 2026 at 5:03 AM Andrzej Białecki <[email protected]> wrote:
>>> 
>>>> Hi all,
>>>> 
>>>> A lot of good work already went into branch_10x - dependency updates and
>>>> important bug fixes. There are also some outstanding bugs that I know about
>>>> (SOLR-18414, SOLR-18408 and related CrossDC bugs) that either cripple or
>>>> completely break certain use cases in 10.0.0.
>>>> 
>>>> Solr 10.0.0 has been released exactly 6 months ago. I think it’s time for
>>>> 10.1. If the community thinks so too, I volunteer to be the release
>>>> manager. Also, please let me know of any issues that may hold up this
>>>> release.
>>>> 
>>>> Andrzej
>>>> ---------------------------------------------------------------------
>>>> 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]

Reply via email to