I'd like to consider getting SOLR-15919 <https://issues.apache.org/jira/browse/SOLR-15919> into 9.0 because I'm not sure if it would be allowed in 9.1. I just realized we would want this while looking at the code tonight, don't even have a patch to present yet.
It would be a fairly substantial change to the public API of SolrZkClient, which I'm not sure if we consider client facing or not. However, I feel like the change would be low risk given that we are already often converting between File and Path in the implementations. Would I need to start a separate thread for it to discuss? On Tue, Jan 11, 2022 at 4:24 PM Joel Bernstein <joels...@gmail.com> wrote: > I think the key is to get 9.0 out the door so we can start regular > releases again. I'm excited about vector search as well but it will be > impactful in 9.0 or 9.1. > > I'll be adding more documentation also for the new the Temporal Graph > features in Solr 9.0 (SOLR-15197). With the new DAY and WEEKDAY time > widows this is a Fintech event correlation tool. > > Existing documentation for temporal graph queries are here: > > > https://github.com/apache/solr/blob/main/solr/solr-ref-guide/src/graph.adoc#temporal-graph-expressions > > > > Joel Bernstein > http://joelsolr.blogspot.com/ > > > On Mon, Jan 10, 2022 at 5:21 PM Jan Høydahl <jan....@cominvent.com> wrote: > >> I don't disagree with you that it is cool with announcements of killer >> features. But we have known for almost 2 years that 9.0 is eventually >> coming, but still chose to backport every single cool feature to 8.x, >> leaving less for the 9.0 release. And I cannot blame us, since we all >> thought of 9.0 as something in the far future. Still, the best interest of >> the project and our users is getting what we have out there, not stalling >> releases for 4, 5, 6 months. So hopefully first RC in 3-4 weeks from now.. >> Blocker JIRAs that have not seen active work towards completion will be >> candidates for demotion, except blockers that are about security or compat >> break. If we are almost ready with "Killer feature Y" when time for RC1 >> comes, then let's talk, maybe it is ready to be included in Beta state? But >> if it is still a month or two away, it has to jump on the next train. >> >> There is still time to propose JIRAs to be added as blockers. I hear >> people complain about lack of features but I don't see anyone saying >> "Please can I add SOLR-XYZ, as blocker, I'm going to work hard and polish >> it and make sure it is ready by DD.MM". >> >> If we, after 4-5 weeks of stabilization still doubt the stability / >> reliability of the entire release, then we should consider a 9.0.0-BETA. It >> would however be very useful if you outline exactly what functionality you >> currently feel is beta quality, and why. >> >> I have earlier proposed that we can choose to label only a certain >> Feature-X as BETA, by tagging it's documentation as such and mentioning it >> in the release notes, e.g. "Solr 9.0.0 features a BETA version of vector >> search..." I.e. we could have a non-beta Solr release with a few features >> in beta, promoting them to GA in a later point release. If I remember >> right, Noble claimed during the release of the package manager that we >> could not tag a single feature as BETA, but I disagree. I think it is a >> good practice, to pre-release a feature as beta if we cannot guarantee it's >> quality in the first release. >> >> Finally, I'd also like to remind us that we are now 100% free as a >> project to plan for a 10.0.0 (Solr X) release even before Lucene 10 is out, >> with bells and whistles and cool features from here to the moon, Java 17 >> and what we like. Just a though. We are free. >> >> Jan >> >> 10. jan. 2022 kl. 21:58 skrev David Smiley <dsmi...@apache.org>: >> >> Major releases are special, not like minor releases. More people will >> look at what's neat in a major release than a minor one. It's a de facto >> PR event for the project to *potentially* shine. If Lucene or whatever >> project didn't use them to its advantage years ago then it was a missed >> opportunity. Also, just as importantly, it's a rare event to make >> backwards-incompatible changes. So I don't think we should release a major >> version simply because someone is willing to go through the procedures to >> do so. Of course this is motivated by 8x being in feature freeze, which we >> are somewhat beholden to because of our unfortunate wedlock with Lucene >> that is not yet fully severed. Yes, we all knew this time was coming and >> we were all busy and didn't get to some of the things we all wanted to do >> -- (heavy sigh). Personally, a metaphorical fire is under my butt to try >> to make the changes in Solr I want, and I hope you all are mustering the >> time to do likewise. I'm not sure if they will all make Jan's deadlines or >> not. Scant few are marked release blockers because in my mind it's more of >> a best-effort. >> >> A beta version would help here -- a "real" release that may not have all >> of the changes we want to make yet -- be they cool things like vector >> search or backwards-incompatible changes. It could also give us a >> reasonable excuse to ship some features and have them be refined >> subsequently. >> >> ~ David Smiley >> Apache Lucene/Solr Search Developer >> http://www.linkedin.com/in/davidwsmiley >> >> >> On Mon, Jan 10, 2022 at 3:32 AM Jan Høydahl <jan....@cominvent.com> >> wrote: >> >>> Hi Cassandra, >>> >>> I browsed through the confluence page and the Antora project a bit. >>> Looks like many good reasons for doing the move, and the new structure at >>> https://nightlies.apache.org/solr/draft-guides/solr-reference-guide-antora/solr/HEAD/index.html >>> looks very promising. >>> I'll not stand in the way of this for 9.0. It is not a code change >>> jeopardizing Solr stability. The only thing it may challenge is open PRs >>> that need editing of reorganized refguide files, but that will happen >>> anyway. >>> >>> I also see that there is lots of work left wrt deployment, >>> multi-version, UI part, a non-released gradle plugin etc. I see Hoss has >>> been involved, hope others can lend a hand too. >>> I see you note that it may be hard to build the guide locally, so >>> perhaps this is the time to let the official guide be built by Jenkins >>> triggered on every commit to release-branches, that changes the folder? >>> I hope local workflow won't be bogged down if ref-guide needs to build >>> 10 versons back from different branches every time? Or perhaps there could >>> be a separate antora playbook for single-version build? >>> Multi-version support is cool, but is there a way to add some static >>> links in that dropdown menu that would take you to historic online versions >>> such as 8.x? >>> >>> I'll certainly assist in updating release process in whatever way >>> necessary. >>> >>> Jan >>> >>> 9. jan. 2022 kl. 17:09 skrev Cassandra Targett <casstarg...@gmail.com>: >>> >>> One thing we haven’t talked about yet is the Ref Guide for 9.0. >>> >>> SOLR-14444 re-organized the entire guide and changed a lot of page >>> names. At the time I merged this into the main branch there was a little >>> bit of comment about trying to provide page redirects for the changed page >>> names but AFAIK no one has worked on that yet at all (SOLR-15557). >>> >>> Then I embarked on trying to move us to use Antora instead of Jekyll ( >>> https://cwiki.apache.org/confluence/display/SOLR/Antora+Migration+Notes), >>> which when complete will dramatically change page URL paths. It would be >>> sensible and less disruptive for users if we only make page name/path >>> changes once, but it isn’t ready yet. >>> >>> I could try to make a big push to get it done, but I will need some >>> help, and of course it is a major change so sort of technically violates >>> the intent of code freeze so I won’t kill myself if folks are going to balk >>> at some point in February if it does actually get done in time. >>> On Jan 9, 2022, 7:56 AM -0600, Jan Høydahl <jan....@cominvent.com>, >>> wrote: >>> >>> Hi, >>> >>> This is quite simple. >>> - The 9.0 release is on-going - now on branch_9_0 >>> - The normal feature feeze rules apply. Anything explicitly approved as >>> blocker gets in >>> >>> We can still consider adding features to the branch if the benfit/risk >>> ratio is high enough. Having a long stabilization period also helps. But >>> please ask before merging. >>> >>> The discussion whether we have "enough features" is i.m.o. silly, that's >>> not how it works, we release as often as possible, and major versions >>> annually. But this time around we wanted to wait for Lucene 9 which was >>> also delayed. Now, after almost 2 years on 8.x we have Java11, Lucene 9, >>> gradle build, embedded Docker image and tons of litle improvements for devs >>> as well as users. 8x is in bugfix mode so no new feature releases there. We >>> are currenlty blocked from getting ANY new feature into our users hands. >>> >>> Wrt node roles, it was not ok to knowingly sabotage the feature freeze, >>> but I'm not going to revert your commit. I'll put the incident on the >>> branch-confusion account. The feature appears to be backward compat and >>> high benefit, but it touches lots of core code paths, so I'd say there is a >>> medium/high risk of introducing new bugs. If you do not intend to revert, >>> please follow test failures and other feedback wrt that feature closely. >>> I'd also wish the Admin UI would show roles in some way. You can see the >>> properties in dashboard, but can you see the resolved roles for nodes >>> explicitly anywhere? I'm also surprised not to find an explicit NODE_ROLES >>> variable in solr.in.sh for a prominent feature like this - it would be >>> so much easier for e.g. solr-operator to configure roles for a node if it >>> was contained in a single env-var. >>> >>> Wrt vector search, it may go in if it is ready soon-ish, guess the code >>> is isolated enough to be low-risk, it can also be called out as >>> experimental. But i'm not willing to delay the release another month or >>> more (March-April?) just to wait for yet another feature. >>> >>> I'm excited to get 9.0 into the hands of users. Let's make this happen! >>> >>> Jan >>> >>> >>> 9. jan. 2022 kl. 08:16 skrev Ishan Chattopadhyaya < >>> ichattopadhy...@gmail.com>: >>> >>> > 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. >>> >>> Apache Solr is a search engine. In that list, except for the UI page for >>> SQL, I don't see a new *search* related feature. A major release without >>> any compelling feature will keep users from upgrading. I don't understand >>> the hurry now when the vector search support is just around the corner. Why >>> can't we make an exception for that particular feature and include it in >>> the release, if it gets ready before the release? >>> >>> On Sun, Jan 9, 2022 at 11:35 AM Ishan Chattopadhyaya < >>> ichattopadhy...@gmail.com> wrote: >>> >>>> > Ishan, that also means that you only need to revert SOLR-15694 on >>>> branch_9_0 >>>> >>>> In Apache Solr, committers don't tell other committers to revert >>>> commits without a proper technical justification. You were late in cutting >>>> the release branch for 9.0, and now "need" me to revert my commit because >>>> you're not comfortable with the commit making it to the release? >>>> >>>> This is very demoralizing. When contributors work for months on a >>>> feature, they hope to see a released version of Solr with that feature. In >>>> the case of SOLR-15694, we took several extra steps to ensure broader >>>> community participation. If you still demand of me to revert the commit, >>>> I'll comply since I don't want to hold up this release. In that case, I'll >>>> backport to a 8.12 release so that users can use the feature sooner than >>>> waiting another 2-3 months for a 9.1 release. >>>> >>>> On Sun, Jan 9, 2022 at 11:05 AM Noble Paul <noble.p...@gmail.com> >>>> wrote: >>>> >>>>> The New feature list for 9.0 is >>>>> >>>>> * Replica placement plugins >>>>> * Rate limiting and task management >>>>> * Certificate Auth Plugin >>>>> * SQL Query interface in UI >>>>> >>>>> None of these are compelling search features which will motivate >>>>> anyone to upgrade OTOH , vector search is a very attractive feature >>>>> and even if it we release that as "experimental" users are likely to >>>>> upgrade >>>>> >>>>> So, please consider including that >>>>> >>>>> >>>>> On Sun, Jan 9, 2022 at 11:35 AM Jan Høydahl <jan....@cominvent.com> >>>>> wrote: >>>>> > >>>>> > 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 <jan....@cominvent.com>: >>>>> > >>>>> > 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 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 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 < >>>>> ichattopadhy...@gmail.com>: >>>>> > >>>>> > > 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 < >>>>> ichattopadhy...@gmail.com> 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 . 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 is open, >>>>> PR 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 >>>>> >>>>>>>> >>>>> >>>>>> >>>>> >>>>> >>>>> >>> >>>>> > >>>>> > >>>>> >>>>> >>>>> -- >>>>> ----------------------------------------------------- >>>>> Noble Paul >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >>>>> For additional commands, e-mail: dev-h...@solr.apache.org >>>>> >>>>> >>> >>> >>
