Summary, Dev Chat, July 31, 2024

Announcements

There were no announcements this week.

Forthcoming Releases

Next minor releaseMinor 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.: 6.6.2

@hellofromtonya confirmed the status of 6.6.2:

• No schedule yet for it.
• @hellofromtonya and @jorbin suggested tentatively scheduling a regular maintenance release for late August unless something critical requires that schedule to change.

Next major releasemajor 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.: 6.7

We are currently in the WordPress 6.7 release cycle. WordPress 6.7 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. 1 is scheduled for Tuesday, October 1.

@jorbin asked what timeframe we want to consider early for the purposes of the TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. keyword. There was no consensus in the meeting, but this provides an opportunity to improve our documentation to avoid confusion about what this keyword means. @joemcgill offered to review if someone wants to attempt to improve the docs about the early keyword in our handbook.

@mikachan reported that she checked in with @priethor about an update on the release squad for 6.7 and expects to have an update sometime next week.

Discussion

@mikachan led with this update:

I’d like to note that WordCamp US is coming up on September 17–20, and @Courtney has begun requesting table leads from all the Make teams for Contributor DayContributor Day Contributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://2017.us.wordcamp.org/contributor-day/ https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/.. Please let her know if you’re interested in leading a table for the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. team, and feel free to ask questions in #core.

Open Floor

@nikunj8866 raised two issues for discussion:

• #40477
  • @joemcgill suggested that this could use a review from a REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. maintainer
  • @hellofromtonya identified the need for an owner and automated tests
  • @spacedmonkey offered to take a look
• #13459
  • @jorbin suggests that it needs automated tests

@spacedmonkey raised a question about #60414:

What defines “ready to commit” for this ticketticket Created for both bug reports and feature development on the bug tracker. and tickets of this size? What are the next steps to get a ticket like this merged into core? How many core committers need to sign off on it? Can it be committed in WP 6.7?

This question was previously raised and discussed in this #core-committers conversation in Slack and summarized by @hellofromtonya in this Trac comment.

@jorbin identified the biggest thing needed to move this forward is having multiple committers who are willing to drive consensus and finalize the implementation before it is committed. @hellofromtonya shared these three proposed steps that @jorbin had previously shared in the Slack conversation:

1. Getting the patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. on a dotorg sandbox and making sure it doesn’t blow up .org.
2. Getting this on a large host so we can see how it performs in the myriad conditions core runs
3. Making sure that wp-cliWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/ doesn’t break

Additional conversation about the proposal ended with @mikachan suggesting that a good next step might be an updated post for make/core, since there are still many questions to resolve.

Note: Anyone reading this summary outside of the meeting, please drop a comment in the post summary, if you can/want to help with something.

Props to @mikachan for proofreading.