Riad Benguella 8:46 am on December 19, 2018
Tags: core-editor ( 715 ), gutenberg ( 489 )

Gutenberg commits and merge status update

In the last weeks, we froze merging PRs in the GutenbergGutenberg 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 ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ repository to allow us to strictly control what gets shipped in 5.0 and 5.0.x releases.

This has served us well to ensure the stability of the releases. At the same time, the number of approved and unmerged PRs kept growing in the repository. After some discussions and feedback, it’s time to make some adjustments to our merging workflow:

A g-minor 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". has been created in the GithubGitHub 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 ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ repository based on the last package release.
Critical bugbug 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 can be cherry-picked to this branch in order to be integrated into 5.0.x releases.
Package releases can be performed from the branch.

In parallel:

We’ll start merging approved PRs to the master branch iteratively. Initially, let’s limit merging PRs to those explicitly assigned to the 4.8 milestone.
The merged PRs will be shipped in the next Gutenberg pluginPlugin 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/ or can be cost-based plugin from a third-party releases.
No package release will be performed from the master branch.

As a consequence, the plugin releases and the WordPress release will diverge more and will be aligned for each major WordPress release.

#core-editor, #gutenberg

Xavi Ivars 9:02 am on December 19, 2018

Thanks for the update! Does that mean that new PRs that include new features that affect only the editor (not consider strictly bugs, but not Phase2 features) won’t be incorporated into WP 5.0.x, right?

I guess this makes complete sense assuming WP release cadence will increase, and we’re not waiting for Phase2 to release next major version of WordPress. Otherwise, current major WP may offer a much poorer user experience than WP+GutenbergGutenberg 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 ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/.
- Riad Benguella 9:12 am on December 19, 2018
  
  > Does that mean that new PRs that include new features that affect only the editor (not consider strictly bugs, but not Phase2 features) won’t be incorporated into WP 5.0.x, right?
  
  Yes, that’s the idea, the next major 5.1 is expected to be released in February 21. And yes, maybe with the accelerated release cycle, the delay between major releases can be shorter. We’ll adapt the workflow accordingly if needed.
  Otherwise, current major WP may offer a much poorer user experience than WP+GutenbergGutenberg 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 ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/.
  
  That’s true in general for featured plugins as they include enhancements ahead of time, but it’s also a good thing as it allows more iterations and explorations in the pluginPlugin 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/ or can be cost-based plugin from a third-party before merging stable enhancements into CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..
hypest 9:20 am on December 19, 2018

Thanks for this update @youknowriad!

We’ll start merging approved PRs to the master 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". iteratively. Initially, let’s limit merging PRs to those explicitly assigned to the 4.8 milestone.

Let me see if I understand this correctly: after that initial “throttled” period (a few days long perhaps?) `master` will be free to be targeted at any time? Or perhaps again in the future it will “froze”?

I’m basically looking for the signal to try and merge the `mobile` branch back to `master` and delete it.
- Riad Benguella 9:25 am on December 19, 2018
  
  > Let me see if I understand this correctly: after that initial “throttled” period (a few days long perhaps?) `master` will be free to be targeted at any time?
  
  Yes, I’m thinking we’d still limit merging by milestones. 4.8 now, 4.9 in a few days but we can be less restrictive about what we include in these milestones.
  Or perhaps again in the future it will “froze”?
  
  I don’t expect that we freeze merging again in the future. Backporting to `g-minor` is more restricted but we can come back to a regular workflow for master.
  I’m basically looking for the signal to try and merge the `mobile` 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". back to `master` and delete it.
  
  Can you please open a PR for it, we’ll take a quick look at the web impacts of this PR and yes we can probably merge it back for 4.8 (or 4.9 at worst).
  - dekervit 9:53 am on December 19, 2018
    
    We have a PR open for it: https://github.com/WordPress/gutenberg/pull/12582
Anton Timmermans 12:53 pm on December 19, 2018
I think this is the right time for the GutenbergGutenberg 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 ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ repository to adopt gitflow. The huge advantage is that a lot of people already know this model so it is easier to jump into Gutenberg contributing. It also makes a lot of sense naming wise:
- `develop` = 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". under development.
- `master` = Branch with latest released stable version.
`gitflow` also makes explicit what things branches are targeting. When a `hotfix/8.0.1` is created you instantly know that the code is targeted for 8.0.1.
- Anton Timmermans 12:55 pm on December 19, 2018
  
  This all works very well because branches are really cheap in git.
- Riad Benguella 1:34 pm on December 19, 2018
  
  If you think of it, what we propose here is very close: `develop` is `master` in gitflow and `g-minor` is `master` in gitflow. There are some subtle differences though that are very specific to the GutenbergGutenberg 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 ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg//WordPress project:
  
  – The need to sync with WordPress using packages (only happens in g-minor)
  – The need to do pluginPlugin 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/ or can be cost-based plugin from a third-party releases ahead of time to be able to iterate quickly without pushing these changes to the stable 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". and this is addressed by doing plugin releases from master.
  - Anton Timmermans 2:35 pm on December 19, 2018
    My proposal to address these constrains would be:
    
    Follow `gitflow` for package releases. This addresses the first constraint. `release/5.0.2` is aligned with the WordPress release. This is in line with our process anyway. If we want to be more specific we can do `wordpress-release/5.0.2`.
    
    Use a temporary release 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". for pluginPlugin 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/ or can be cost-based plugin from a third-party releases based off `develop`, merged back into `develop`. Called `plugin-release/4.8`. This addresses the second constraint.
    
    So branch make up looks like this:
    
    `master` contains the release of the packages for the latest stable WordPress release.
    
    `release/5.0.3` contains the latest code slated for the 5.0.3 minor WordPress release.
    
    `develop` contains the latest stable release for the next WordPress major & the next plugin release.
    
    `plugin-release/4.8` contains the latest code for the 4.8 plugin release.
    
    I can make a visual overview if you want me to about how this would work.
    - Andrew Duthie 2:56 pm on January 2, 2019
      
      What would be the cadence / 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". on which package releases would occur under a more Gitflow-oriented model? As it stands today (and best I can tell, doesn’t change by the proposal), publishing packages can occur without there being a corresponding pluginPlugin 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/ or can be cost-based plugin from a third-party or WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. release. In the inverse though, a WordPress release corresponds to specific tagged published packages; the same isn’t necessarily true for plugin releases, though perhaps it should.
      - Anton Timmermans 12:33 pm on January 7, 2019
        
        As the package releases match the WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. releases, I would release them from that 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"..
        
        If you want package releases for the pluginPlugin 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/ or can be cost-based plugin from a third-party releases, then those would have increase the minor (not 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.) for every package. That is to leave room for a possible patch release for a package for core.
        
        I think the only sane way to do this is to say WordPress core production release === Packages production release. That also aligns with the monorepo idea.

Comments are closed.

Welcome!

Communication

Gutenberg commits and merge status update

Welcome!

Communication

Share this: