I tend to Agree with David We should have a compelling feature in Solr 9 which will encourage users to try it out. Solr 9 does not have any such feature and it is mostly a cleanup that most users do not really care about.
+1 to include SOLR-15880 (even if we have to release it as experimental) On Fri, Jan 7, 2022 at 8:24 AM David Smiley <dsmi...@apache.org> wrote: > 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 <thelabd...@gmail.com> > wrote: > >> thanks Jan, PR looks good now! đ >> >> >> On Thu, Jan 6, 2022 at 11:52 AM Jan Høydahl <jan....@cominvent.com> >> 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 <jan....@cominvent.com>: >>> > >>> > 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 <thelabd...@gmail.com>: >>> >> >>> >> 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 <jan....@cominvent.com> >>> 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: dev-unsubscr...@solr.apache.org >>> >> For additional commands, e-mail: dev-h...@solr.apache.org >>> >> >>> > >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >>> For additional commands, e-mail: dev-h...@solr.apache.org >>> >>> -- ----------------------------------------------------- Noble Paul
