It is obviously confusing to treat 9x banch as release branch and main as both 10.0 and 9.next. I can symphatize with wanting a place to land 9.1 backports right now.
If we continue with current setup and wait with cutting 9_0, committers could adapt a workflow like this * Merge your PR to main * Create a feature branch from branch_9x with the backport, and open a PR against branch_9x (dropdown in GitHub9 * Whenever you do followup commits or bug fixes on main for your new feature, backport those to the 9x feature branch * When branch_9_0 is created, merge the PRs It's a bit more involved, but so is having three live branches that needs cherry-picking for all the stabilization work in the coming weeks. Perhaps they are equally burdensome? Jan > 7. jan. 2022 kl. 19:39 skrev Houston Putman <[email protected]>: > > 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] > <mailto:[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 > <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] >> <mailto:[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 >>> >> >
