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 RC 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/4.7'
  2. $ svn merge -c 12345 '^/trunk'
  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/4.7 checkout that has no code changes other than what’s being merged and a test sitesite (versus network, blog) 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 makemake A collection of P2 blogs at make.wordpress.org, which are the home to a number of contributor groups, including core development (make/core, formerly "wpdevel"), the UI working group (make/ui), translators (make/polyglots), the theme reviewers (make/themes), resources for plugin authors (make/plugins), and the accessibility working group (make/accessibility). 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 generally be copied from the trunk commit(s), but adds a new line between Props and Fixes which says, “Merges [trunk changeset ID] to the 5.0 branch.” For an example, see r43276.

Note: Makemake A collection of P2 blogs at make.wordpress.org, which are the home to a number of contributor groups, including core development (make/core, formerly "wpdevel"), the UI working group (make/ui), translators (make/polyglots), the theme reviewers (make/themes), resources for plugin authors (make/plugins), and the accessibility working group (make/accessibility). sure to run the above commands from 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". root, and not from a sub directory. The reason for this is that the svn:mergeinfo is a SVNSVN Subversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase. property on /branches/4.7 which the SVN client sets, it’s not a server side thing.

At the bottom of https://core.trac.wordpress.org/browser/branches/4.7 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 patch to each branch, you still need to record the merge metadata with:

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

Last updated: