Merge trunk into release/1.18.0

[bcotrim]

Related issues

• Related to the 1.18.0 release (code freeze refresh)

How AI was used in this PR

Claude verified the merge is content-identical to trunk and regenerated the RELEASE-NOTES.txt draft using the same GitHub generate-notes call the code_freeze lane makes.

Proposed Changes

1.18.0 slipped to Friday, so the Aug 6 freeze is 58 commits behind trunk. This brings release/1.18.0 back up to trunk and refreshes the draft release notes so they cover everything actually shipping in 1.18.0.

Nothing on the release branch is lost: git merge-tree --write-tree origin/release/1.18.0 origin/trunk produces the same tree as origin/trunk^{tree}, i.e. the merge is a no-op against trunk.

The notes are still the auto-generated draft — the Pre-Release step curates them the way 1.17.0's section was.

Testing Instructions

• The 1.18.0 section of RELEASE-NOTES.txt lists 149 PRs, ending at Agentic UI: Wait for the remote import before reporting a push complete #4522.
• After merging, git diff origin/trunk origin/release/1.18.0 is empty (barring anything new landing on trunk meanwhile).

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?

[AliSoftware]

@bcotrim ⚠️ The direction of this PR feels very suspicious to me, because that means that you're adding everything that was done in trunk into the currently flying release/1.18.0 release branch…

I'm not 100% how much of your team's release process might differ from how we do it in other apps, but usually we cut release/1.18.0 branch from trunk when we start the code-freeze (to freeze the code, that we plan to ship as a version 1.18, for the duration of beta-testing / smoke-testing the changes before sending it to end users), and then merge release/1.18 into trunk (not the other way around)

By having this PR merging trunk into release/1.18, i.e. the other way around, this means you suddenly will include many new PRs and features/fixes, that have landed in trunk way after you cut release/1.18.0 branch to freeze the code for version 1.18 on Aug 6. This means that the release/1.18 which presumably already started its beta-testing will suddenly get a buttload of new features and PRs that landed in trunk and were not there at the time you code-froze release 1.18 initially.

Maybe that is intentional for some reason (due to a different way you do your release process in studio that I'm not aware of, or a rationale for an exception this time around that I'm missing), but just wanted to flag it to be extra sure that adding so many commits and trunk PRs into the release/1.18.0 branch 1 week after its code-freeze was intentional vs a misclick in the direction you created this PR?
Marking as "Request changes" until I get more info to ensure it's not merged accidentally by habit, happy to revise the review if this is truly justified and not an error

[AliSoftware]

Maybe I should have read the PR description more carefully before jumping to look at the diff and replying hastily though 😅

Related to the 1.18.0 release (code freeze refresh)

This brings release/1.18.0 back up to trunk and refreshes the draft release notes so they cover everything actually shipping in 1.18.0.

Still would love a double-confirmation to be extra sure, given how uncommon this is and how easily it could have been an AI misinterpreting a prompt the wrong way. Happy to approve once you confirm 🙂

[wpmobilebot]

📊 Performance Test Results

Comparing 6f7fc94 vs trunk

app-size

Metric	trunk	6f7fc94	Diff	Change
App Size (Mac)	1406.83 MB	1406.83 MB	+0.00 MB	⚪ 0.0%

site-editor

Metric	trunk	6f7fc94	Diff	Change
load	1082 ms	995 ms	87 ms	🟢 -8.0%

site-startup

Metric	trunk	6f7fc94	Diff	Change
siteCreation	7513 ms	7512 ms	1 ms	⚪ 0.0%
siteStartup	2870 ms	2866 ms	4 ms	⚪ 0.0%

---

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change (<50ms diff)

[bcotrim]

My intention is to bring everything from trunk now into a new code freeze for the next release.
Context: We decide to postpone the release planned to last Monday to this Friday in order to bring in more changes: p1786370404658569/1786359730.635619-slack-C06DRMD6VPZ

My plan is to merge this trunk (once approved and green CI) and proceed with the release normally by creating a new beta and running smoke tests. Does this look good?

Thank for the review @AliSoftware 🙇

[AliSoftware]

My intention is to bring everything from trunk now into a new code freeze for the next release. Context: We decide to postpone the release planned to last Monday to this Friday in order to bring in more changes: p1786370404658569/1786359730.635619-slack-C06DRMD6VPZ

My plan is to merge this trunk (once approved and green CI) and proceed with the release normally by creating a new beta and running smoke tests. Does this look good?

Ok sounds good 👍
So basically it's to make it as if you started the release/1.18 today instead of last week (i.e. it's the same end result as if you closed/deleted the release/1.18.0 branch and started the code-freeze for 1.18.0 all over again) right?

Then if that's the goal, then this makes sense to me, and reassures me that this was intentional and not a misclick or mistake 👍 Approving now.

[bcotrim]

Exactly!

So basically it's to make it as if you started the release/1.18 today instead of last week (i.e. it's the same end result as if you closed/deleted the release/1.18.0 branch and started the code-freeze for 1.18.0 all over again) right?

I didn't consider closing/deleting the release branch and starting a new code freeze, would that have made things cleaner? Next time we could do it differently

[AliSoftware]

PS: May I suggest to use "Add Notes" in ReleasesV2 to leave breadcrumbs about this decision in the release 1.18.0?

I think something like below will be enough, but given ReleasesV2 is meant to be the source of truth for anyone in the company who wants to follow-along the status of the release, or for your future selves to understand what happened (and why the dates changed) when you might look at stats or release retrospectives in many months, leaving a breadcrumb in ReleasesV2 would allow to connect the dots 🙂

We have decided to delay the Studio 1.18 release to Friday Aug 14. I have updated the dates on this release scenario accordingly, and merged trunk back into the release/1.18.0 branch on Aug 13 to include in 1.18 all the features/fixes PRs that landed on trunk since. See #4536 and p1786370404658569/1786359730.635619-slack-C06DRMD6VPZ

[AliSoftware]

Nice catch remembering to update the release notes 👍

[AliSoftware]

Exactly!

So basically it's to make it as if you started the release/1.18 today instead of last week (i.e. it's the same end result as if you closed/deleted the release/1.18.0 branch and started the code-freeze for 1.18.0 all over again) right?

I didn't consider closing/deleting the release branch and starting a new code freeze, would that have made things cleaner? Next time we could do it differently

I think both are ultimately OK and mostly equivalent… though now that I think of it, we may be missing some details (especially translatable strings, see below) with the way you did it here.

Personally I think I'd probably have gone with "delete the branch and redo the code-freeze again" mostly because:

• it would maybe have felt less confusing to me when looking at the git graph or not wondering if a PR merging trunk to release/* was intended while unusual (but that point might be subjective)
• and also because by re-doing the code-freeze process you ensure that all the little actions that are done as part of the code-freeze, mostly:
  • The drafting of the release notes (9eb0b31) — but you remembered to update those in this PR so that one is ok
  • The update of the translatable strings (0d4d002) — That one might need re-generating if new strings were introduced in the .ts source code in trunk that you're now merging in release/1.18.0?
  • The update of the translations (2424a5a) — Ditto

So maybe re-doing the code-freeze to ensure the string bundles are regenerated to include potential new strings introduced in trunk since would be worth it…?
Or alternatively we could re-run the scripts / fastlane lanes in charge of updating those translatable strings and translations in this PR (or as a follow-up in release/1.18.0 once this PR lands) to make sure they are in sync.

The only risk that I identify of redoing the code-freeze is that the new code-freeze will redo a version bump (54334b6) to 1.18.0-beta1 and if an artifact with that name already exists in Apps CDN I'm not sure if it'll just replace it or fail due to it already existing (but it that happens we could always manually bump to 1.18.0-beta2 in a dedicated commit in the newly-recreated release/1.18.0 I guess?)

[AliSoftware]

@bcotrim I looked at the Fastfile and what were the details of what we are doing in code_freeze and new_beta_release.

TL;DR: It's ok to merge this instead of deleting the release/ branch and creating it anew, as long as we verify the .pot file is up-to-date too

As part of the code_freeze:

  generate_pot_file(
    commit_message: "[skip ci] Code freeze: Update translatable strings for #{version}",
    skip_confirm: skip_confirm
  )

  # Generate draft release notes from PRs merged since the last published release
  update_release_notes_draft(version: version)
  git_add(path: ['RELEASE-NOTES.txt'])
  git_commit(
    path: ['RELEASE-NOTES.txt'],
    message: "[skip ci] Code freeze: Add draft release notes for #{version}",
    allow_nothing_to_commit: true
  )

  push_to_git_remote(set_upstream: true)

And in this PR you already did a04be14) the update of the release notes (what the update_release_notes_draft(…) call + subsequent git_commit does) 👍 so that covers the replay of what was done in 9eb0b31 in the original code-freeze and we should be good there

But what might be missing and could be worth re-doing is the call to generate_pot_file, to redo what was done in 0d4d002 during the original code-freeze. And commit this into release/1.18.0 via a follow-up PR if the diff it generates is not empty.

As part of the new_beta_release

The other commit I saw being done on the release/1.18.0 branch on Aug 6 as part of when you started the 1.18.0 release was 2424a5a [skip ci] Update translations. But those commits are done as part of new_beta_release, not as part of code_freeze:

  fetch_glotpress_translations
  git_add(path: [TRANSLATIONS_DIR])
  git_commit(
    path: [TRANSLATIONS_DIR],
    message: '[skip ci] Update translations',
    allow_nothing_to_commit: true
  )

So this is not really a major problem:

• This it will just be done again next time you create a new beta (actually I see you already created such a beta2, and it indeed generated a new commit c58b43d for [skip ci] Update translations.
• This will also be done when you'll do the final release, to be sure we get the latest translations before shipping the final build too. So nothing to worry about for that part.

---

In conclusion, the only thing worth checking is if re-running the generate_pot_file action will produce a diff worth commiting, so that potential new strings introduced in trunk since release/1.18.0 was first cut would be sent to translation too. I'll try to run it locally to see if there's any diff

[bcotrim]

Nice catch @AliSoftware, thanks for checking that! 🙇
It seems delete the branch and starting a new code freeze would have made things easier.

[AliSoftware]

I'll try to run it locally to see if there's any diff

Done: #4541