# Title: Updating Core with Gutenberg Features - - - ## 📚 Metadata: - Author: Joe McGill - Source: [Make WordPress Article](https://make.wordpress.org/core/2023/08/01/proposal-improve-the-editor-tech-workflow-for-major-releases/) - Tags: #blockeditor , #gutenberg , #releaseprocess #WordPress - - - ## 📝 Summary: The article discusses the challenges faced when updating core with the latest features from the Gutenberg plugin. It proposes the idea of syncing Gutenberg code to core earlier in the release cycle to mitigate the difficulties and reduce risks during major release milestones. However, implementing this idea has been hindered by differences in Gutenberg's iterative development process, leading to unstable code in the plugin. The article also highlights issues related to the package ecosystem, occasional hiccups caused by breaking changes in dependencies from Gutenberg. To address these challenges, it suggests improving documentation for the development process, regenerating the package-lock file in Gutenberg, and prioritizing dependency-related breakage fixes. ## 📖 Main Content: 1. Updating core with Gutenberg features has been a major pain point, resulting in problems and delays during release time. 2. The proposed solution is to sync Gutenberg code with core earlier in the release cycle to catch bugs early, test new features in trunk, and reduce risks during major releases. 3. Challenges with Gutenberg's development process include iterative code development starting with experimental processes and multiple features in development leading to unstable code. 4. Mechanisms to avoid merging unstable code into core exist, but their enforcement is not consistent, creating room for improvement. 5. Improving documentation of expectations for the development process could aid in ensuring contributors are aware of existing rules and their purpose. 6. Core consumes Gutenberg code as npm packages, causing occasional hiccups due to breaking changes in dependencies noticed in core but not in Gutenberg. 7. The suggestion is to regenerate the package-lock file in Gutenberg and commit it back when packages are published, prioritizing fixing dependency-related breakage. 8. Early nomination of the release team can ensure continuity and ownership of ongoing issues during the development process. 9. The core workflow of committing changes to trunk before backporting them to the release branch poses challenges in updating packages with the latest changes from Gutenberg. 10. The sync process can start after the stable release, allowing time for testing and issue resolution. ## 💡 Implications: The proposal to sync Gutenberg code with core earlier in the release cycle has the potential to lead to more stable and reliable major releases for the WordPress community. Addressing challenges related to unstable code and package ecosystem issues could result in smoother and more efficient development processes. Improved documentation and consistent enforcement of code stability guidelines may lead to better code management and collaboration among contributors. ## 🔮 Future Research: 1. Investigate methods to enforce mechanisms that prevent merging unstable code consistently during Gutenberg development. 2. Research the impact of early synchronization on reducing release-related stress and risks for open-source contributors. 3. Analyze the benefits of regenerating the package-lock file in Gutenberg and its impact on dependency-related issues. ## 🧪 Hypotheses: 1. Hypothesis 1: Syncing Gutenberg code with core earlier in the release cycle will result in more stable and reliable major releases. 2. Hypothesis 2: Consistent enforcement of mechanisms to prevent merging unstable code during Gutenberg development will reduce code-related issues during releases. 3. Hypothesis 3: Improved documentation of the Gutenberg development process will increase contributor adherence to code stability guidelines. 4. Hypothesis 4: Regenerating the package-lock file in Gutenberg will lead to early detection and resolution of dependency-related breaking changes. 5. Hypothesis 5: Nominating the release team in advance will facilitate smoother transitions and ongoing issue ownership during development cycles. ## 📊 Methodology: 1. Data Collection: - Gather historical data on release-related problems caused by updating core with Gutenberg features. - Collect data on the frequency and impact of breaking changes in dependencies from Gutenberg. ## References: 1. [Make WordPress Article](https://make.wordpress.org/core/2023/08/01/proposal-improve-the-editor-tech-workflow-for-major-releases/) ## Links - [[Open Source Governance MOC]] — connects Gutenberg-to-core integration work to release governance and shared maintenance decisions. - [[Default-Off Feature Flags Decouple Shipping Speed From Production Risk]] — applies-in: experimental Gutenberg work can land earlier when merge timing is separated from user exposure. - [[npm Lockfiles Are Resolver-Version Specific]] — evidence-for: regenerating and committing the package lock at publication time makes the resolver environment part of the release artifact instead of an implicit local assumption.