IMPORTANT Just created branch_9_0 off of branch_9x, and bumped version on branch_9x to 9.1.
This means that everything is back to normal branch structure, and the feature freeze is now only on branch_9_0. Ishan, that also means that you only need to revert SOLR-15694 on branch_9_0, and let it remain on branch_9x, while you let it bake. I also added these Jenkins jobs: - Solr-Artifacts-9x - Solr-Check-9.x - Solr-reference-guide-9.x - Solr-Artifacts-9.0 - Solr-Check-9.0 - Solr-reference-guide-9.0 Jan > 9. jan. 2022 kl. 01:04 skrev Jan Høydahl <[email protected]>: > > Hi, > > This is indeed a deliberate deviation from established branch process, as > debated and decided in the "Solr 9.0.0 release in February" thread > https://lists.apache.org/thread/pzqvmcxcjhkrj2xb31sj3pwzrn6x9vd3 > <https://lists.apache.org/thread/pzqvmcxcjhkrj2xb31sj3pwzrn6x9vd3> and > repeated on this very thread, so this is far from some SNEAKY attempt to > trick you all :) However, the intent of minimizing number of backports in a > period where the project is in 9.0 release focus (there will be tons of > commits) seemd brilliant just a week ago, but I can see that we also need a > place to land 9.1 features now and not wait until February. > > As several committers are in support of freeing branch_9x for feature > development for 9.1, I'll go ahead and create the branch_9_0 branch now. > > Ishan: What warrants a release is subjective, but noone can accuse the Solr > project of RUSHING with the 9.0 release. Have a look at the Major Changes in > Solr 9 > <https://nightlies.apache.org/solr/draft-guides/solr-reference-guide-main/major-changes-in-solr-9.html> > page if you need a reminder of what we have been keeping from our users (and > developers not the least) for too long. > Someone will always have a "killer feature" around the corner. Fine, then 9.1 > will also get a nice killer feature. Or 9.2. More champagne! But lack of a > brand new feature is never a blocker for any release. > > Jan > >> 8. jan. 2022 kl. 02:45 skrev Ishan Chattopadhyaya <[email protected] >> <mailto:[email protected]>>: >> >> > branch_9x is in feature freeze! We want to stabilize >> >> Feature freeze is meant for the release branches. There is no precedent for >> having a feature freeze on the stable branch. I urge you to follow well >> established processes and not invent new processes on the fly and hold the >> project hostage to those new processes. If you have concerns about the >> stability of the commit, we can consider reverting from the stable branch. >> >> On Sat, Jan 8, 2022 at 7:11 AM Ishan Chattopadhyaya >> <[email protected] <mailto:[email protected]>> 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? >> +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 >> > <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 >> <https://twitter.com/jobergum/status/1476657317768749062> >> >> >> On Sat, Jan 8, 2022 at 5:15 AM Jan Høydahl <[email protected] >> <mailto:[email protected]>> 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 >>> <[email protected] <mailto:[email protected]>>: >>> >>> 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] <mailto:[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] >>> <mailto:[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] <mailto:[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] >>>> <mailto:[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] >>>>> <mailto:[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 >>>>> <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 >>>>> <http://www.linkedin.com/in/davidwsmiley> >>>>> >>>>> On Thu, Jan 6, 2022 at 2:11 PM Timothy Potter <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> thanks Jan, PR looks good now! 😀 >>>>> >>>>> >>>>> On Thu, Jan 6, 2022 at 11:52 AM Jan Høydahl <[email protected] >>>>> <mailto:[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] >>>>> > <mailto:[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] >>>>> >> <mailto:[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] >>>>> >> <mailto:[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 >>>>> >>> <https://lists.apache.org/thread/qv9n2b7jkmzr26ov5p50lc3h2dy7htzo> >>>>> >>> [2] https://issues.apache.org/jira/issues/?filter=12351219 >>>>> >>> <https://issues.apache.org/jira/issues/?filter=12351219> >>>>> >> >>>>> >> --------------------------------------------------------------------- >>>>> >> To unsubscribe, e-mail: [email protected] >>>>> >> <mailto:[email protected]> >>>>> >> For additional commands, e-mail: [email protected] >>>>> >> <mailto:[email protected]> >>>>> >> >>>>> > >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> <mailto:[email protected]> >>>>> For additional commands, e-mail: [email protected] >>>>> <mailto:[email protected]> >>>>> >>>> >>> >> >
