Agree. Will cut the branch tomorrow or Thursday. Current list of 9.0 blockers: https://issues.apache.org/jira/issues/?filter=12351219 Please jump in and help with the ones you care for.
PS: I found a bunch of issues assigned to the "9.0" fixVersion, I moved them all to "main (9.0)" which is the correct version to use for 9.0. Jan > 3. jan. 2022 kl. 20:08 skrev David Smiley <[email protected]>: > > I completely agree with Houston; let's not create branch_9_0 yet. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > <http://www.linkedin.com/in/davidwsmiley> > > On Mon, Jan 3, 2022 at 11:36 AM Houston Putman <[email protected] > <mailto:[email protected]>> wrote: > I think its fine to start with just branch_9x until we are ready to actually > do the release, even if it is unconventional for our processes. There’s no > need to have a branch_9_0 until there are actual reasons that 9x and 9_0 > would differ (i.e. 9.0.0 is ready to be released and people want to add > things for 9.1.0). > > On Mon, Jan 3, 2022 at 10:31 AM Jan Høydahl <[email protected] > <mailto:[email protected]>> wrote: > Happy New Year everyone! > > According to my initial mail it's now time to cut branch_9x. However, I'm in > the middle of some build and build-script tuning, so it may delay a few days > more. > > I'm also wondering whether it's better to cut both branch_9x and well as > branch_9_0 so everyone can continue adding features for 9.1, with the cost of > having to do another backport for every fix that is targeted for 9.0. Will it > be confusing to treat branch_9x as a feature-frozen release-branch for all of > January? > > Jan > >> 21. des. 2021 kl. 20:03 skrev David Smiley <[email protected] >> <mailto:[email protected]>>: >> >> Thanks for volunteering to be the RM! >> >> No comment on the timeline; I'm in denial of the time flying. Log4shell and >> all that. >> >> Let's go to Lucene 9.1 and not 9.0. I'm seeing a massive change to >> lucene-test-framework in 9.1 on it's way that IMO ought to have been done in >> 9.0. Going right to 9.1 averts issues there for Solr users writing plugins. >> >> You're right RE blockers -- it's always tough to let go of our >> ideals/hopes/dreams on what we want 9.0 to be. >> >> ~ David Smiley >> Apache Lucene/Solr Search Developer >> http://www.linkedin.com/in/davidwsmiley >> <http://www.linkedin.com/in/davidwsmiley> >> >> On Tue, Dec 21, 2021 at 10:57 AM Jan Høydahl <[email protected] >> <mailto:[email protected]>> wrote: >> Hi, >> >> Solr's next feature release will be 9.0 (as 8x is in bugfix mode). >> Let's not even think about hacking an 8.12 release based on lucene-solr 8x >> branch. It will be ugly. >> >> The "Solr 9.0 release blockers" thread >> <https://lists.apache.org/thread/m7k2gvgxldkns7jqjnw1ghhqx7s3tpl1> was >> started exactly 2 months ago to try to prepare us. But we're moving slowly. >> The same happened for Lucene, until the 9.0 release :) So I'll start the >> train right now... >> >> I propose the following rough roadmap: >> >> December: Cut branch_9x next week and enter feature freeze on that branch >> January: Remove blockers, prepare build & release machinery, including Docker >> February: Cut branch_9_0 and build RC1 - branch_9x is again re-opened for >> new features >> >> I volunteer as RM. >> >> Wrt blockers, we need to be tough on ourselves and ask the question "Is it >> possible to release 9.0 without this?".. >> At the end of January we should have only a few real blockers left, that are >> all actively in progress. >> The delay between branch_9x and branch_9_0 is to avoid having to backport >> everything twice during the hardening phase. >> >> Jan >> >
