Backporting Commits

When porting a commit from trunk back to versioned branches, it’s best done by different committercommitter A developer with commit access. WordPress has five lead developers and four permanent core developers with commit access. Additionally, the project usually has a few guest or component committers - a developer receiving commit access, generally for a single release cycle (sometimes renewed) and/or for a specific component. than the one who made the trunk commit, as an extra layer of review. During the RCrelease candidate 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). phase, at least two committers must sign off on any commit.

Do not commit to multiple branches in the same commit. This will, at a minimum, break the GitGit Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Git is easy to learn and has a tiny footprint with lightning fast performance. Most modern plugin and theme development is being done with this version control system. https://git-scm.com/. mirrors.

A basic SVNSVN Subversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase. flow to backportbackport A port is when code from one branch (or trunk) is merged into another branch or trunk. Some changes in WordPress point releases are the result of backporting code from trunk to the release branch. a commit could look like this:

  1. $ svn switch '^/branches/5.9'
  2. $ svn merge -c 12345 '^/trunk' where 12345 is the changeset ID.
  3. $ svn ci

If the fix in trunk required multiple separate commits, you can backport them all in a single command like this:

svn merge -c 10001,10002 '^/trunk'

For merges you should generally use a pristine branches/5.9 checkout that has no code changes other than what’s being merged and a test site for testing the merged commit on (which you should always do).

Also, although you’ll probably never need it, if you’re merging multiple commits one after each other, don’t forget to run svn up between them. If what you need to merge has multiple commits, also feel free to squash them down for the branchbranch 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". commit to make it easier for everyone reading.

Sometimes multiple changes to the same code are made in trunk before they are ported to a branch.  In this case, you will get conflicts, so be sure to port the older changesets as well.  Committers asking for a backport should indicate this situation on the ticketticket Created for both bug reports and feature development on the bug tracker..

To add the merge info afterwards you can run svn merge --record-only -c 12345 '^/trunk'.

The branch commit message will largely be copied from the trunk commit(s) with a few updates. Please see the commit message documentation, especially the sections on Merges and Reviewed By.

Make sure to run the above commands from the branch root, and not from a sub directory. The reason for this is that the svn:mergeinfo is a SVN property on /branches/5.9 which the SVN client sets, it’s not a server side thing.

At the bottom of https://core.trac.wordpress.org/browser/branches/5.9 you see two links, ‘merged’ and ‘eligible’. The second one shouldn’t list commits which are already merged.

Security Backports

Security fixes are backported to many versions, and are not committed until the day of a release. Because of this, the process can be streamlined a bit.

You should still make individual commits to trunk and the current branch, but on the older branches you can make a single commit with all of the fixes for that branch. Do not commit to multiple branches at once, though.

When committing the bulk patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. to each branch, you still need to record the merge metadata with:

svn merge --record-only -c 12345,12347,12349 '^/trunk'

Last updated: