Hi, I did a successful test-build of an RC with the releas wizard yesterday, with 0 test failures (what's the chance of that :) ? Currently fixing the smoke tester to accept the new docker/ folder we added to the structure and a few more things. Once I have a passing smoketester locally we are a big step closer to actually being able to go through with a release.
Currently giving some attention to failing tests. Please everyone check out http://fucit.org/solr-jenkins-reports/failure-report.html and try to fix the worst offenders. I think we currently have the HDFS tests under control and also TestBadConfig. The SolrExporterIntegrationTest is being handled. Jan > 13. jan. 2022 kl. 03:31 skrev Mike Drob <[email protected]>: > > 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 <[email protected] > <mailto:[email protected]>> 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 > > <https://github.com/apache/solr/blob/main/solr/solr-ref-guide/src/graph.adoc#temporal-graph-expressions> > > > > Joel Bernstein > http://joelsolr.blogspot.com/ <http://joelsolr.blogspot.com/> > > > On Mon, Jan 10, 2022 at 5:21 PM Jan Høydahl <[email protected] > <mailto:[email protected]>> 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 <http://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 <[email protected] >> <mailto:[email protected]>>: >> >> 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 >> <http://www.linkedin.com/in/davidwsmiley> >> >> On Mon, Jan 10, 2022 at 3:32 AM Jan Høydahl <[email protected] >> <mailto:[email protected]>> 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 >> >> <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 <[email protected] >>> <mailto:[email protected]>>: >>> >>> 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 >>> <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 <[email protected] >>> <mailto:[email protected]>>, 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 <http://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 >>>>> <[email protected] <mailto:[email protected]>>: >>>>> >>>>> > 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 >>>>> <[email protected] <mailto:[email protected]>> 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 <[email protected] >>>>> <mailto:[email protected]>> 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 <[email protected] >>>>> <mailto:[email protected]>> 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 <[email protected] >>>>> > <mailto:[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 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 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 >>>>> >>> <[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]> >>>>> >>>>>>>> >>>>> >>>>>> >>>>> >>>>> >>>>> >>> >>>>> > >>>>> > >>>>> >>>>> >>>>> -- >>>>> ----------------------------------------------------- >>>>> Noble Paul >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> <mailto:[email protected]> >>>>> For additional commands, e-mail: [email protected] >>>>> <mailto:[email protected]> >>>>> >>>> >> >
