Technical organisation post-5.0

Once WordPress 5.0 is released, the intention is to have a minor WordPress release twice a month. These releases will be focused on editor improvements and bug fixes. They can also include bug fixes beyond the editor.

Repositories

Work on the editor will continue on GitHub, while work on WordPress Core will continue in Trac. The JavaScript packages from GitHub, which represent more than just Gutenberg code, will be updated on a regular basis and merged into WordPress Core.

A typical Workflow for a Core bug fix involving a JavaScript package will follow this process:

  1. A Trac ticket is created to track the bug resolution.
  2. If the issue is found to be related to a JavaScript package, a corresponding GitHub issue is created referencing the Trac ticket.
  3. The issue is resolved in a GitHub pull request and merged to master.

Then, on a regular basis, the Editor Team will:

  1. Publish updates to the WordPress npm packages from the Gutenberg repository.
  2. Update the packages in Core.
  3. Close the Trac tickets fixed by the packages update.

In addition to the editor improvements, prototypes, and implementation of Phase 2 work will also happen in the GitHub repository. We will use feature flags to avoid including the Phase 2 work in the WordPress Core package updates. This will allow us to continue using the Gutenberg plugin releases for beta testing.

Deprecation policy for JavaScript APIs

There hasn’t been a decision made yet on the process for deprecating JavaScript APIs. Discussions around a comprehensive deprecation policy have started in #core-js. Some ideas around script versioning and more prominent deprecation notices will be explored. Once those discussions have a clear outcome a post will be made to this blog (Core P2).

During the plugin phase, the deprecation strategy of the Gutenberg APIs went through several iterations:

  • In the early days, all the APIs were considered experimental, which meant that there were no expectation of backward compatibility between plugin releases.
  • Once the plugin became more stable and widely used, we started ensuring backward compatibility for all the APIs for at least 2 versions of the plugin.

This strategy won’t be applied in Core because it’s very important that we continue to maintain the user trust with auto-updates and there’s no intention in changing that in the future.

That said, maintaining backward compatibility for JavaScript APIs has costs. It’s impactful and it can harm the user experience. Maintaining APIs indefinitely is not a reasonable approach as we can’t keep loading more kilobytes of JavaScript as we add new APIs and support old ones.

If you have thoughts on the subject, please join the discussions in the #core-js Slack Channel and share your ideas during our weekly meetings (Each Tuesday at 14h/2pm UTC).

#5-0