Since a 9.0 release branch has not been cut, I backported the SOLR-15694 to branch_9x. If there are any concerns, we can discuss reverting it from branch_9_0 later. Thanks and regards.
On Fri, Jan 7, 2022 at 10:34 PM Ishan Chattopadhyaya < [email protected]> wrote: > > let it bake in main (10.0) for some time, letting more devs try it out > > Please define "some time". Is 3 weeks until the 9.0 release not enough? > > On Fri, Jan 7, 2022 at 10:26 PM Jan Høydahl <[email protected]> wrote: > >> I think it is premature to add it to branch_9x yet. First get +1 from key >> stakeholders on the PR, then let it bake in main (10.0) for some time, >> letting more devs try it out. If all looks good at that point, we may >> consider it, especially if the default behaviour is === 8.x. >> >> What do others think? >> >> Jan >> >> 7. jan. 2022 kl. 11:26 skrev Ishan Chattopadhyaya < >> [email protected]>: >> >> > Btw - does Solr have any benchmarks published yet, that we can compare >> 8.11 with 9.0? Would be very useful. >> >> I can work on it over the weekend. I have some suites ready with me, but >> not automated yet. >> >> >* Today*: Cut branch_9x and enter feature freeze on that branch >> >> I'd like to include SOLR-15694 (node roles) in 9.0, if that's okay with >> you. It is dev complete, we're just running the tests to make sure the >> failing tests are not due to our changes (and unrelated); we can commit it >> over the weekend. >> >> On Fri, Jan 7, 2022 at 3:13 AM Jan Høydahl <[email protected]> wrote: >> >>> I don't think we are allowed by Apache policy to broadly announce >>> non-official releases like nightlies. >>> >>> There should be more than enough in 9.0 to warrant a major release. >>> Most users will be reluctant to jump on a X.0.0 release, so we can >>> mature a lot in 9.0.x. >>> >>> Perhaps if we start authoring the Release Notes (any volunteers?), we'll >>> see more clearly what we are about to relase. >>> And if we can have new sexy features in 9.1 and 9.2 that even warrants >>> blog posts and twitter bragging, even better :) >>> >>> Let's keep this release train rolling and force ourselves into getting >>> this out there sooner rather than later. We're not releasing the >>> reference-branch or anything, so I think a beta is not necessary, unless >>> the release phase ends up in endless RCs due to tons of bugs and >>> regressions. >>> >>> Btw - does Solr have any benchmarks published yet, that we can compare >>> 8.11 with 9.0? Would be very useful. >>> >>> Jan >>> >>> 6. jan. 2022 kl. 22:24 skrev David Smiley <[email protected]>: >>> >>> What do we think about a "beta" release, to give users (including >>> *ourselves* in many cases) more time to try out 9.0 to report issues? I >>> don't think a beta release would necessitate a typical feature freeze. If >>> we ultimately decline on a beta release, a counter-proposal would be to >>> promote our nightly docker images everywhere (solr-users list, twitter, >>> Slack) to solicit feedback. >>> >>> It would be a shame to release Solr 9 without support for the vector >>> based index in Lucene 9. Thankfully there's a JIRA issue with a PR! >>> https://issues.apache.org/jira/browse/SOLR-15880 . It's as much about >>> optics as anything. I think many users are probably more at a curiosity / >>> exploratory stage with this topic but still -- Solr 9 without the ability >>> to explore this is disappointing, leaving them to consider other options to >>> scratch that itch. >>> >>> ~ David Smiley >>> Apache Lucene/Solr Search Developer >>> http://www.linkedin.com/in/davidwsmiley >>> >>> >>> On Thu, Jan 6, 2022 at 2:11 PM Timothy Potter <[email protected]> >>> wrote: >>> >>>> thanks Jan, PR looks good now! 😀 >>>> >>>> >>>> On Thu, Jan 6, 2022 at 11:52 AM Jan Høydahl <[email protected]> >>>> wrote: >>>> >>>>> False alarm, I had a dirty checkout. >>>>> Please see if your PR passes precommit. >>>>> >>>>> Jan >>>>> >>>>> > 6. jan. 2022 kl. 19:49 skrev Jan Høydahl <[email protected]>: >>>>> > >>>>> > Tim, I pushed a change to gradle that now uses hardcoded 9.0.0 for >>>>> tests.luceneMatchVersion. That's a stop-gap, will make it dynamically >>>>> follow the current lucene-version, but somehow my gradle project picked up >>>>> an old version of org.apache.lucene.utils.Version class... >>>>> > >>>>> > Now I get a new error >>>>> > >>>>> > * What went wrong: >>>>> > Execution failed for task ':validateSourcePatterns'. >>>>> >> Found 10 violations in source files (@author javadoc tag, svn >>>>> keyword, tabs instead spaces). >>>>> > >>>>> > Jan >>>>> > >>>>> >> 6. jan. 2022 kl. 17:53 skrev Timothy Potter <[email protected]>: >>>>> >> >>>>> >> Thanks for the update Jan! >>>>> >> >>>>> >> One of my PRs (sync'd with main) is now failing precommit with: >>>>> >> >>>>> >> 105 actionable tasks: 103 executed, 2 up-to-date >>>>> >> 201FAILURE: Build failed with an exception. >>>>> >> 202 >>>>> >> 203* Where: >>>>> >> 204Script >>>>> '/home/runner/work/solr/solr/gradle/validation/solr.config-file-sanity.gradle' >>>>> >> line: 40 >>>>> >> 205 >>>>> >> 206* What went wrong: >>>>> >> 207Execution failed for task ':solr:validateConfigFileSanity'. >>>>> >> 208> Configset does not refer to the correct luceneMatchVersion >>>>> >> (10.0.0): >>>>> /home/runner/work/solr/solr/solr/server/solr/configsets/_default/conf/solrconfig.xml >>>>> >> 209 >>>>> >> >>>>> >> Any ideas what's wrong there? >>>>> >> >>>>> >> On Thu, Jan 6, 2022 at 9:40 AM Jan Høydahl <[email protected]> >>>>> wrote: >>>>> >>> >>>>> >>> NOTICE: >>>>> >>> >>>>> >>> Branch branch_9_x has been cut and versions updated to 10.0 on >>>>> 'main' branch. >>>>> >>> >>>>> >>> This follows the plan from previous notice about 9.0 release [1]. >>>>> Here is what will happen: >>>>> >>> >>>>> >>> Today: Cut branch_9x and enter feature freeze on that branch >>>>> >>> Next few weeks: Remove blockers, prepare build & release machinery >>>>> >>> February: Cut branch_9_0 and build RC1 >>>>> >>> >>>>> >>> This is how we'll use the branches until we cut the branch_9_0 >>>>> release-branch: >>>>> >>> >>>>> >>> main: All new features and bug fixes (as today) >>>>> >>> branch_9x: Only backport of bugfixes and blockers for the 9.0 >>>>> release. >>>>> >>> >>>>> >>> >>>>> >>> FAQ: >>>>> >>> ------ >>>>> >>> Q: Where do I put a feature intended for 9.1? >>>>> >>> A: On main branch. Then in February, bulk backport to branch_9x >>>>> >>> >>>>> >>> Q: Can we go to Java17 on main branch now? >>>>> >>> A: Not yet, let's keep main branch as-is until branch_9_0 is cut, >>>>> to easen backporting >>>>> >>> >>>>> >>> Q: But my feature is almost ready and low-risk, I can surely put >>>>> it on branch_9x ? >>>>> >>> A: No, only blockers and bugfixes please. You can argue on dev@ >>>>> that your feature is a blocker >>>>> >>> >>>>> >>> Q: How can I help with the 9.0 release? >>>>> >>> A: You can check out the JIRA for blockers [2] and help fix those >>>>> >>> >>>>> >>> Q: Why do we need to wait until February with cutting the release >>>>> branch? >>>>> >>> A: We don't - if blockers are resolved and we feel close to RC1 >>>>> before then... >>>>> >>> >>>>> >>> >>>>> >>> [1] >>>>> https://lists.apache.org/thread/qv9n2b7jkmzr26ov5p50lc3h2dy7htzo >>>>> >>> [2] https://issues.apache.org/jira/issues/?filter=12351219 >>>>> >> >>>>> >> >>>>> --------------------------------------------------------------------- >>>>> >> 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] >>>>> >>>>> >>> >>
