Forthcoming releases 🚀
WordPress 6.8.1
@jorbin proposed to lead the next minor release A set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality. and to host a first 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. scrub right after the devchat.
There has been discussion about the need for a WordPress 6.8 retrospective post. Several people have pointed out the lack of interest of this kind of initiative in recent releases. Members of the 6.8 release squad are still welcome to share their thoughts. @jeffpaul pointed out that the goal is to find ways to ensure the next release cycle is easier than the last: What should be stopped (because it doesn’t help); what should the Core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. team start doing (because it would be helpful); what should be changed (because iterating would be better). Ideally the release squad could put together a Make/Core blogpost and invite people to comment to share their thoughts.
Discussion about the WordPress 6.8.x cycle
With no other major release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope. scheduled in 2025, 6.8.x is going to be a long cycle, comparable to cycle 4.9.x.
@jeffpaul and @michelleames published a Make/Core post to gather nominations for folks to help lead the 6.8.x minors.
@jeffpaul: “If folks find something and are not certain if it should be part of 6.8.1 (or any future minor release), then please drop a link in #6-8-release-leads […] to help further triage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors..”
@audrasjb asked whether the Core team should open milestones 6.8.2 and 6.8.3 on Trac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress., but @jorbin pointed out that it’s better to avoid having multiple milestones open for minors except when the current one is on the RC One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). step.
@joemcgill suggested that once any immediate issues that need to ship in a 6.8.1 release are addressed, the Core team could have a broader conversation about how they want to operate for the rest of the year, given that only minor releases are expected. His preference would be to identify a few volunteers to put together a proposal that we can get feedback on before finalizing the process, with a few things we need to consider: How does the ongoing development of JS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. package in the GB 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 affect how the Core team plan minor release updates, etc. ; How much change do the Core team allow in trunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. during this period, given that large changes make it more difficult to backport A port is when code from one branch (or trunk) is merged into another branch or trunk. Some changes in WordPress point releases are the result of backporting code from trunk to the release branch. fixes to the 6.8 branch 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". ; What types of tickets are “allowed” to be shipped in a minor over the rest of the year, since no more major releases is expected this year.
@jeffpaul pointed out that the Core team had a decent precedent (4.9.6, with privacy features) that expanded what can happen in minors. If there are ways to expand beyond that that won’t break things (e.g. updater), then let’s explore those but there may still be relatively hard constraints.
A minor release is intended for bugfixes and enhancements that do not add new deployed Launching code from a local development environment to the production web server, so that it's available to visitors. files and are at the discretion of the release lead The community member ultimately responsible for the Release. with suggestions/input from component maintainers and committers.
Source: Releasing Minor Versions in the Core Handbook
@joedolson suggested the team should consider that the first couple point releases could be reserved to new issues only, the same as most minor releases, and once those are settled, the scope of minors can start to be expanded. But the drift between trunk and minors could be difficult to manage, especially if the scope of what can go into a minor is too restrictive. @audrasjb confirmed that it’s exactly what was done during cycle 4.9.x: the cycle started with bug fixes introduced in version 4.9, the the Core team started to introduce enhancements with 4.9.5 and all along the rest of the cycle.
For now, there is a hard rule, though: No new file can be introduced in a minor release.
@jorbin encouraged Core contributors Core contributors are those who have worked on a release of WordPress, by creating the functions or finding and patching bugs. These contributions are done through Trac. https://core.trac.wordpress.org. to publish their own ideas on their own blogs so then all the ideas can be shared and the Core team could come up with a plan.
@joemcgill volunteered to to coordinate a proposal for Make/Core, unless more guidance is given. He would welcome ideas that folks want to share (please feel free to reach out with him).
Open Floor 💬
Core Trac Workflow Keywords Issue
The discussion concerns an issue raised by @sirlouen on Meta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. about a conflict A conflict occurs when a patch changes code that was modified after the patch was created. These patches are considered stale, and will require a refresh of the changes before it can be applied, or the conflicts will need to be resolved. between the "needs-testing" and "needs-testing-info" keywords in search results on WordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ Meta Trac (Ticket Created for both bug reports and feature development on the bug tracker. 7935). This problem makes reports, especially for the testing team, more difficult and leads to incorrect information. Two solutions were suggested: renaming one of the keywords or improving the search algorithm. The conversation continues in the Trac comments.
@sirlouen wanted to run a poll/survey to close this ticket in the next Core Test meeting (23rd April), but he would like to have the consensus (and the awareness) from the core team that this is going to happen, and It’s going to bring a change in core. This item is scheduled for discussion during the next dev chat.
