A reminder on Solr 10 blockers (updated URL): https://issues.apache.org/jira/issues/?jql=project%20%3D%20SOLR%20AND%20priority%20%3D%20Blocker%20AND%20fixVersion%20%3D%2010.0%20%20AND%20resolution%20is%20EMPTY%20ORDER%20BY%20updated%20ASC
We're gonna have to get realistic and push off some of these. No release is perfect. Backwards incompatible / API changes are probably easiest & most important on this list for a major release. On Fri, Oct 24, 2025 at 3:19 AM Andy Webb <[email protected]> wrote: > hi all, > > I have a PR ready for https://issues.apache.org/jira/browse/SOLR-17959 > which would allow users to disable edismax's "ignore stopwords if all terms > are stopwords" feature. > > This is low priority - just something I was surprised by while prototyping > and found I couldn't disable. I'd *like *to get it into 9.10.0 and 10.0.0, > but waiting for 10.1.0 would be fine too. > > My understanding is that to bring this into 10.1.0 I'd just need to merge > the PR into main and add it to branch_10x. For 9.10.0 and 10.0.0 I'd > additionally need to add it to branch_9x (by Tuesday) and branch_10_0 (only > with Anshum's blessing). If it doesn't go into 10.0.0 it should never go > into 9.10.0+, correct? > > If anyone has thoughts on the change itself please let me know on the > ticket/PR, but otherwise is it OK if I add this to branch_9x and > branch_10_0 please? > > thanks, > Andy > > On Thu, 23 Oct 2025 at 22:37, Chris Hostetter <[email protected]> > wrote: > > > > > : release branch. Until 10 is actually released, why would we commit to > > : main, branch_10x, and *not* branch_10_0? The answer is stuff going to > > 10.1 > > : but really can't we just defer back-porting such changes? Then the RM > > can > > > > Corret: New features might be "ready" and suitable for 10.1 but not > > suitable for 10.0 (which is in feature freeze) > > > > If you commit these features to main (but not 10x) and "wait" until > > after 10.0 to backport them, you risk them being forgotten about (and you > > complicate other "new feature" backports to branch_10x for people who > > *are* ready to backport them. > > > > The question "Can't we just defer back-porting such changes?" could be > > applied to any level of branching... > > > > We could also eliminate ever needing a branch_10x, and only use "main" > for > > all feature development, if people just agreed to make a note of what > > features are suitable for 10.x and which need to wait for 11.x -- and > then > > when brancH_10_1, (or branch_10_2, etc...) is created, go through that > > list and backport all the "10.x suitable" features -- but that moves all > > of the pain of backporting (and jenkins testing) to a short window of > time > > before each release. > > > > > > -Hoss > > http://www.lucidworks.com/ > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
