: 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.
At a glance, I would arguee that these are the two most concerning items... 1) SOLR-17938 - main & branch_10x builds currently use a non-trusted third party maven repo 2) SOLR-17840 - How badly is LTR broken on main & branch_10x ? : 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] : > > : > > : > : -Hoss http://www.lucidworks.com/
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
