Solr 4 had both an Alpha and Beta release. Came with essentially full release cost, just indicated broad confidence in the initial releases and that users should give it a spin if possible to allow a more reasonable .0 release.
[Mark Miller - Chat @ Spike](https://spikenow.com/r/a/?ref=spike-organic-signature&_ts=1db2cr) [1db2cr] On January 6, 2022 at 21:43 GMT, Jan Høydahl <jan....@cominvent.com> 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 <dsmi...@apache.org>: 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
