{"id":124256,"date":"2026-06-30T03:24:39","date_gmt":"2026-06-30T03:24:39","guid":{"rendered":"https:\/\/make.wordpress.org\/core\/?p=124256"},"modified":"2026-06-30T15:28:35","modified_gmt":"2026-06-30T15:28:35","slug":"guidelines-for-syncing-code-from-gutenberg-into-wordpress-develop","status":"publish","type":"post","link":"https:\/\/make.wordpress.org\/core\/2026\/06\/30\/guidelines-for-syncing-code-from-gutenberg-into-wordpress-develop\/","title":{"rendered":"Guidelines for Syncing Code From Gutenberg Into WordPress Develop"},"content":{"rendered":"

During the 7.0 release cycle, the way code maintained in the GutenbergGutenberg<\/span> The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses \u2018blocks\u2019 to add richness rather than shortcodes, custom HTML etc.\rhttps:\/\/wordpress.org\/gutenberg\/<\/a><\/span><\/span><\/span> repository is imported into the wordpress-develop<\/code> repository changed from using published npm packages to downloading a zip file of built assets published to the GitHubGitHub<\/span> GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the \u2018pull request\u2019 where code changes done in branches by contributors can be reviewed and discussed before being merged by the repository owner. https:\/\/github.com\/<\/a><\/span><\/span><\/span> Container Registry by the build-plugin-zip.yml<\/code> workflow file in Gutenberg (see #64393<\/a>, Gutenberg-75844<\/a>).<\/p>\n\n\n\n

There were two bugs preventing wordpress-develop<\/code> from being updated with the latest changes (Gutenberg-76715<\/a> and #65418<\/a>). These have been fixed and after [62577-62578,62580-62584<\/a>],\u00a0 trunk<\/code> is now in sync with the most recent gutenberg<\/code> release (currently 23.4.0<\/code>).<\/p>\n\n\n\n

To set expectations and establish some consistency going forward, this post outlines the process for syncing the two repositories going forward, and how to perform the syncing process.<\/p>\n\n\n\n

Syncing Practices<\/h2>\n\n\n\n

The following sections aim to define when and how to sync changes from the gutenberg<\/code> repository into the wordpress-develop<\/code> repository.<\/p>\n\n\n\n

Cadence During Alpha Periods<\/h3>\n\n\n\n

For the 7.1 release cycle, syncing will happen one week after each general release of Gutenberg<\/strong>. This ensures that trunk<\/code> is reasonably up to date with the latest changes, but still allows some time for any follow-up bugbug<\/span> A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.<\/span><\/span><\/span> fixes that are required. The goal is to eventually sync weekly, or even daily.<\/p>\n\n\n\n

Syncing During The Release Cycle BetaBeta<\/span> A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process.<\/span><\/span><\/span>\/RCrelease candidate<\/span> One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta)<\/a>.<\/span><\/span><\/span> Phase<\/h3>\n\n\n\n

Once the Beta 1 point is reached for a release, the SHA value pinned to gutenberg.sha<\/code> in package.json<\/code> for trunk<\/code> will be updated to one belonging to the release\u2019s corresponding wp\/X.Y<\/code> branchbranch<\/span> A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a \"branch\", such as \"the 4.0 branch\".<\/span><\/span><\/span> in the Gutenberg repository when the next syncing occurs. trunk<\/code> will remain pinned to a wp\/X.Y<\/code> branch hash value until branching occurs. This prevents new feature work not intended for the upcoming WordPress release from leaking into the SVNSVN<\/span> Subversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase.<\/span><\/span><\/span> code base.<\/p>\n\n\n\n

Because individual changes targeted for an upcoming WordPress release are cherry-picked into each wp\/X.Y<\/code> branch, syncing can happen as often as necessary. However, the most recent changes must be synced prior to each beta<\/code> and RC<\/code> release.<\/p>\n\n\n\n

Branching in WordPress SVN<\/h3>\n\n\n\n

After branching is performed in WordPress coreCore<\/span> Core is the set of software required to run WordPress. The Core Development Team builds WordPress.<\/span><\/span><\/span> SVN, the new numbered branch in SVN will remain pinned to the corresponding wp\/X.Y<\/code> branch in the Gutenberg repository.<\/p>\n\n\n\n

After branching, the trunk<\/code> branch should be bumped to X.Y+1-alpha<\/code> (example [62161]<\/a>) and a second commit should be made changing the pinned SHA value back to the most recent Gutenberg pluginPlugin<\/span> A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https:\/\/wordpress.org\/plugins\/<\/a> or can be cost-based plugin from a third-party.<\/span><\/span><\/span> release in trunk<\/code>, thus syncing all of the changes since Beta 1. Making two commits creates two distinct reference points: one for bumping the version, one for documenting all of the changes being synced into the code base from Gutenberg.<\/p>\n\n\n\n

Note: <\/strong>Branching typically happens<\/a> immediately after the RC1 release is published for an upcoming major version. But in some cases, branching can be delayed or moved up based on factors unique to the current release.<\/p>\n\n\n\n

Post-Branching in WordPress SVN<\/h3>\n\n\n\n

After branching has occurred for an upcoming major releasemajor release<\/span> A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope.<\/span><\/span><\/span> and the numbered branch is pinned to the corresponding wp\/X.Y<\/code> branch, syncing should happen as often as necessary to ensure the latest changes targeted for that release are included in each Beta and RC release.<\/p>\n\n\n\n

Committers should balance the frequency of updating with the net benefit after considering other factors, such as the severityseverity<\/span> The seriousness of the ticket in the eyes of the reporter. Generally, severity is a judgment of how bad a bug is, while priority<\/strong> is its relationship to other bugs.<\/span><\/span><\/span> of the fix being merged, the non-zero amount of noise each commit makes, contributors needing to pull updates\/merge the latest into their pull requests, the volume of related reports being made, etc. Syncing solely to pull in a typo fix is probably unnecessary. But syncing to only pull in a bug fix for an APIAPI<\/span> An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.<\/span><\/span><\/span> that was broken is worth considering.<\/p>\n\n\n\n

This process will continue during maintenance releases.<\/p>\n\n\n\n

trunk<\/code> will return to being synced during the week opposite Gutenberg plugin releases.<\/p>\n\n\n\n

Example Timeline<\/h3>\n\n\n\n

Using the upcoming 7.1 release as an example, here is a timeline of events:<\/p>\n\n\n\n