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 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. They can also include bug fixes beyond the editor.

Repositories

Work on the editor will continue on GitHub, while work on WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. will continue in TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.. The JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. packages from 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/, which represent more than just 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/ 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 ticketticket Created for both bug reports and feature development on the bug tracker. 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 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 for betaBeta 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. 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 blogblog (versus network, site) (Core P2P2 A free theme for WordPress, known for front-end posting, used by WordPress for development updates and project management. See our main development blog and other workgroup blogs.).

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