If we are doing a "feature freeze" for 9.0, then I think we need to cut branch_9_0. Otherwise there is going to be at least a month of features slated for 9.1 that only get committed to 10x. There are bound to be tickets/commits that fall through and don't end up on branch_9x even though they are supposed to.
In my original comment I mentioned that "unless there is a need for branch_9x and branch_9_0 to differ". There already is, so let's go ahead and cut it. On Tue, Jan 4, 2022 at 3:34 AM Jan Høydahl <[email protected]> wrote: > 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 > > > On Mon, Jan 3, 2022 at 11:36 AM Houston Putman <[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]> >> 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]>: >>> >>> 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 >>> >>> >>> On Tue, Dec 21, 2021 at 10:57 AM Jan Høydahl <[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 >>>> >>>> >>> >
