Thank you everyone for helping work through this slightly different commit management process during the WordPress 5.0 release.
There’s some cleanup work to be done before we can get back to normal, but this shouldn’t take too long. There are 283 commits made to the 5.0 branch 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". that need to be reviewed and ported to
trunk. During WCUS Contributor Day Contributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://2017.us.wordcamp.org/contributor-day/ https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/., @nacin and a few other folks investigated methods for automating this process, but found that it wasn’t a viable option.
Instead, the fastest option is going to be a manual merge. I’ve created a spreadsheet with a list of all of the changes in the 5.0 branch, and the files they touched.
With a couple of workflow considerations, we can use this spreadsheet to avoid getting in each others way, and duplicating work:
- Assign yourself a commit that you’re working on merging. If there are multiple related commits that you’re going to work on, assign them all at the same time.
- There’s no need to commit every changeset individually, particularly those that will be overwritten by a later commit. For example,
.travis.yml changes. Mark the earlier commits as
- If you mark a changeset as
Skipped, leave a note with the reason.
Here are a few reminders while you’re running through changes:
- Please read the Backporting Commits handbook page on best practices. If the
svn merge command doesn’t apply cleanly, and you need to manually merge the commit, you can use the
--record-only switch to record the merge, but not apply the changeset.
trunk is enforcing coding standards, so it’s a good idea to run
composer install when you switch to
composer run format on the files you’re about to commit.
grunt precommit will automatically do this.
- Remember to add relevant information to the commit message:
- “Merges  from the 5.0 branch to trunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision..”
- Copy all props from the original commit.
- “Fixes #54321“, so the relevant ticket Created for both bug reports and feature development on the bug tracker. is auto-closed.
@omarreiss and @atimmer are working on merging the
trunk. All other changes without an assigned committer 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. are up for grabs.
Finally, here is the status of the branches:
The 4.9 branch is in normal status. As the previous major release 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., changes are only back ported on a case-by-base basis. There’s nothing to be merged from the 5.0 branch to the 4.9 branch.
The 5.0 branch is closed until the work on porting changes to
trunk is complete, at which point it returns to normal status. If the porting takes more than a few days, it may be returned to normal status for the purposes of releasing a 5.0.1 beta 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..
Trunk is currently only open for merging changes from the 5.0 branch. After this work is complete, trunk is open for bug 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. fixes, all features should be approved by @matt before committing.