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 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.
- A Trac ticket Created for both bug reports and feature development on the bug tracker. is created to track the bug resolution.
- The issue is resolved in a GitHub pull request and merged to master.
Then, on a regular basis, the Editor Team will:
- Publish updates to the WordPress npm packages from the Gutenberg repository.
- Update the packages in Core.
- 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 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 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. testing.
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.
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).