> 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? +1
> 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. Fully agree with the sentiment here, David. Without the vector search feature, I see no other important enough feature in a 9.0 release to capture users' excitement. Commentators are already writing off Solr as legacy search [0], and such a milestone release should address some of the areas in which we're falling behind. If that feature is just a few weeks out, what is the need for this artificial rush to get 9.0 out now? [0] - https://twitter.com/jobergum/status/1476657317768749062 On Sat, Jan 8, 2022 at 5:15 AM Jan Høydahl <jan....@cominvent.com> wrote: > branch_9x is in feature freeze! We want to stabilize, fix bugs and remove > blockers on that branch, not add features - unless they are agreed as a > blocker for the release. > If everyone starts pushing all kinds of new features to 9x now, it will > never stabilize. > > >>> 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 >>>>> >>>>> > I think it all looks a bit messy and rushed. SOLR-15694 > <https://issues.apache.org/jira/browse/SOLR-15694> is open, PR > <https://github.com/apache/solr/pull/403> is open, with no approvals from > any of the reviwers? > > Please revert on branch_9x and then "argue on dev@ that your feature is a > blocker". > > Jan > > 7. jan. 2022 kl. 20:09 skrev Ishan Chattopadhyaya < > ichattopadhy...@gmail.com>: > > 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 < > ichattopadhy...@gmail.com> 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 <jan....@cominvent.com> >> 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 < >>> ichattopadhy...@gmail.com>: >>> >>> > 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 <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 >>>>>> >>>>>> >>>> >>> >
