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 <[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]> >>>> >>> >
