Sarah Norris 10:44 pm on April 3, 2024
Tags: , , 6-6-release-squad, ,   

Summary, Dev Chat, April 3, 2024

Start of the meeting in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/., facilitated by @joemcgill.

Announcements

WordPress 6.5 “Regina” was released yesterday! Thank you to everyone who worked on, tested, and supported this release 🎉

Forthcoming Releases

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.6

We are officially in the WordPress 6.6 release cycle. @priethor published this WordPress 6.6 Planning Proposal & Call for Volunteers post last week. Please take note of the following callouts on that post:

  • Please leave your feedback about the schedule and release squad size in the comments by April 7th.
  • If you are interested in participating in WordPress 6.6’s release squad as a lead or as a cohort, please show interest in the comments, specifying the role and the type of involvement (lead/cohort).

@colorful-tones and @fabiankaegy will be covering and merging TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress./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/ Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. for 6.6, and if anyone has any recommendations to streamline things for overall Triage to make lives easier, then please reach out to them.

For 6.6, we discussed considering not having a sticky post for the 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. scrub schedule and instead ensuring the schedule is linked at the top of the main release page.

We also discussed 6.5.1, and noted that @jorbin published a post: Initial Bug Scrub for 6.5.1 for tomorrow. @fabiankaegy mentioned that the editor team have created this new board in GitHub to track any editor-related issues that may be candidates for a point 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.. Currently, there are 5 tickets with the backport to wp minor release label.

We also already have quite a few tickets targeted for the 6.5.1 milestone, so any eyes before the initial bug scrub will likely help that be more efficient.

Next Gutenberg release: 18.1

The next Gutenberg release will be 18.1, scheduled for release on April 10, and will include these issues.

Discussion

We began by discussing any potential follow-up actions and reflections following the recent 6.5 release. @fabiankaegy asked about starting a conversation about possibly evolving how we approach the field guideField guide The field guide is a type of blogpost published on Make/Core during the release candidate phase of the WordPress release cycle. The field guide generally lists all the dev notes published during the beta cycle. This guide is linked in the about page of the corresponding version of WordPress, in the release post and in the HelpHub version page. and dev notesdev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. in future releases.

@jorbin has previously opened a related proposal to updating the field guide. We discussed where the most appropriate place was to start a conversation like this, and whether it sits more with CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., Docs, or Project. As it touches on many different areas and how we do things within software release cycles, then it seems to fit more into the Core team’s scope.

@audrasjb suggested this may be good to discuss in the future #6-6-release-squad Slack channel so maybe the squad could discuss it in the open with the future Docs Leads and come up with a formal proposal for 6.6 on Make/Core.

@joemcgill also proposed arranging another release retrospective post to collect feedback about the release while it’s still fresh in people’s minds. @chanthaboune mentioned being able to do this in any way that works for folks. For 6.4, we collected the data in an anonymized format and then that data was shared on make/core, and we discussed potentially following a similar approach for 6.5.

Highlighted posts

The full list of posts from the last week in Core can be read on the agenda at this link.

Open floor

We started by highlighting this PR for the WP Importer in support of the Font Library from @mmaattiiaass.

@kkmuffme mentioned that they’re looking for reviews on several PRs, listed in this message and this message.

Two additional issues that were raised in the agenda comments were:

  • https://github.com/WordPress/gutenberg/issues/15117 – “the excerptExcerpt An excerpt is the description of the blog post or page that will by default show on the blog archive page, in search results (SERPs), and on social media. With an SEO plugin, the excerpt may also be in that plugin’s metabox. regressionregression A software bug that breaks or degrades something that previously worked. Regressions are often treated as critical bugs or blockers. Recent regressions may be given higher priorities. A "3.6 regression" would be a bug in 3.6 that worked as intended in 3.5., that impacts all plugins incl. WooCommerce”
  • https://core.trac.wordpress.org/ticket/59270 – “adding border setting to columns”

This issue was highlighted: Responsive previewing and device-specific editing. Nolan asked what the best way was to make a decision on the issue, as this has been open for 4 years. @annezazu replied with:

I understand that’s an important issue — it has been for a long time! I know some designers have recently chimed in there and there’s some momentum gathering. The best thing to do at this point is to be specific and keep sharing what would be helpful. Beyond that, the main blockerblocker A bug which is so severe that it blocks a release. is finding solid design solutions and finding specific/targeted ways to implement as anything that is implemented has to be maintained.

Also, @webcommsat highlighted a forthcoming 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/. which is looking for core input and people to join. More info on here on Slack.

Props to @joemcgill for reviewing.

#6-5, #6-6, #dev-chat, #summary

Aaron Jorbin 7:06 pm on April 2, 2024
Tags: , ,   

Initial Bug Scrub for 6.5.1

There is no specific target date for WordPress 6.5.1 yet. However, we can start ensuring that all the correct bugs are targeted for it and that work progresses towards fixing them.

To assist with preparation for 6.5.1, an initial scrub will be held at Thursday, April 4, 2024 at 18:00 UTC in the #core slackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel.

Thanks to @desrosj and @hellofromtonya for pre-publication review.

#6-5, #6-5-x, #bug-scrub

Emily Clarke 3:55 pm on April 2, 2024
Tags: , , ,   

Performance Chat Summary: 2 April 2024

Meeting agenda here and the full chat log is available beginning here on Slack.

Announcements

Priority Items

Structure:

  • WordPress performance TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets
    • Current release (WP 6.6)
  • Performance Lab 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 (and other performance plugins)
  • Active priority projects
    • INP research opportunities
    • Improve template loading

WordPress Performance Trac Tickets

  • For WordPress 6.6:
    • We have 14 open items in the 6.6 milestone
    • @joemcgill Given that we’re so early in the cycle, I think the most important thing to discuss is making sure we are making progress on any early tickets, and make sure that any tickets we need to add from our priority projects from our roadmap are included in the 6.6 milestone
    • @joemcgill #59442 is the main one that I’m unsure of, given that it has no owner and is marked early
      • @thekt12 and @spacedmonkey did some work on this, but it still needs some iteration and someone to own finishing it up.
      • @pbearne if no one else is free I can take it on
      • @thekt12 This is more of switching to old commit and adding unit testunit test Code written to test a small piece of code or functionality within a larger application. Everything from themes to WordPress core have a series of unit tests. Also see regression. for it. Should be an easy fix.

Performance Lab Plugin (and other Performance Plugins)

    Active Priority Projects

    Improve template loading

    INP research opportunities

    • @adamsilverstein nothing new from me this week, I’m still working on next steps from the research document I shared last week

    Open Floor

    • @flixos90 On and off over the past year, I’ve been working on a WordPress and performance field research Colab which I’d like to share. This Colab provides a technical introduction and a lot of examples to reference for querying HTTPHTTP HTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands. Archive and CrUX to get WordPress field data, e.g. for things like adoption, performance impact, CWV, …
      • The Colab is effectively already public, and I “silently” added a new short article to the Make Performance Handbook that for now includes it. I’ve also drafted a Make Core post, which I’d like to publish later this week for more visibility, as this can be relevant for any coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. developer.
      • Any feedback on the Colab as well as the new Handbook article and post draft would be much appreciated! Especially the post draft, as that will get more visibility via the Make Core subscribers.
      • If you’re interested in field performance research, you may want to review / work through the Colab in more depth. I’m intending for it to be a “living resource”, so it’ll be updated and expanded in the future. Thank you in advance!
    • @benoitfouc Performant Translationtranslation The process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. feature (I18Ni18n Internationalization, or the act of writing and preparing code to be fully translatable into other languages. Also see localization. Often written with a lowercase i so it is not confused with a lowercase L or the numeral 1. Often an acquired skill.) will avaible for all users with WP 5.6 soon. This feature increase a lot the average performance of all my french websites, thank you so much for working on it. Today WPML was release an update in order to be compatible with Performant Translation https://wpml.org/download/wpml-multilingual-cms/?section=changelog

    Our next chat will be held on Tuesday, April 9, 2024 at 15:00 UTC in the #core-performance channel in Slack.

    #core-performance, #performance, #performance-chat, #summary

    Emily Clarke 12:01 pm on April 2, 2024
    Tags: , , ,   

    Performance Chat Agenda: 2 April 2024

    Here is the agenda for this week’s performance team meeting scheduled for Apr 2, 2024 at 15:00 UTC.

    • Announcements
    • Priority items
      • WordPress performance TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets
        • Current release
        • Future release
      • Performance Lab 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 (and other performance plugins)
      • Active priority projects
        • INP research opportunities
        • Improve template loading
    • Open floor

    If you have any topics you’d like to add to this agenda, please add them in the comments below.

    This meeting happens in the #core-performance channel. To join the meeting, you’ll need an account on the Make WordPress Slack.

    #agenda, #meeting, #performance, #performance-chat

    annezazu 9:29 pm on March 28, 2024
    Tags: ,   

    Providing more clarity in the Gutenberg GitHub Repo

    For a while now, the 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/ 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/ repo has had a few high level labels (Overview, Tracking, Iteration) that have gotten a bit convoluted over time. Sometimes the issue is no longer relevant, is incorrectly labeled, has been updated so many times that the comments don’t follow what’s there, or double labeled. This has led to reported concerns and confusion around what work is truly active, what areas are being explored, and more. To begin to clean this up, a few things were done over the last week or so to make these labels more reliable, more consistent, and easier to follow:

    • Updating the descriptions of these labels to be concise, more descriptive, and show how they are tied to each other.
    • Changing Epic to Iteration for clarity as Epic holds different connotations for folks and is harder to grasp.
    • Triaging older issues and closing out when necessary aka the work is no longer relevant or has been completed.
    • Ensuring the labels that remain are accurate, either by not labeling the work as one of the above labels or adding/removing labels.
    • Pinging the folks who opened different issue when needed to ask for updates to ensure what’s there aligns.
    • Opening any needed overview issues related to phase 3 (this is in progress by @priethor). 

    How can I use or interact with these labels? 

    For context, here’s a sense of how each label should work and how you might want to use them or follow them:

    • Overview issues contain more context/strategy and narrative, often including multiple tracking issues to accomplish an area of work and existing across numerous releases. Here’s an example from phase 2.
    • Tracking issues are more tactical, broken down into individual tasks and areas of work, and exist across a few releases. It should ideally be part of a breakdown from an Overview issue. Here’s an example for layout support.
    • Iteration issues are to define iterations of a project in smaller deliverable packages, including when possible the minimum requirements to ship the iteration as a whole in a WordPress release. Expect these issues to be regularly updated and curated. They reflect more active work and often is pulled out of a list of items in a tracking issue unless the scope is small and it can pull work directly from an Overview. Here’s an example with overrides in synced patterns for 6.6.

    This means if you don’t have a ton of time to pay attention to the releases or overarching work, you can use these labels to narrow your focus and stay up to date at the level you’d like. 

    Label description updates

    This is just a quick rundown of what’s changed, description wise, to tighten up the approach. 

    Before:

    • Epic: A large body of work shaping an iteration that can be broken down into a number of smaller issues.
    • Tracking: For issues used to track large changes across the codebase
    • Overview: Offers a comprehensive breakdown of a specific area of work to act as a guidepost

    After:

    • Iteration: Scoped iteration of an effort from a tracking issue or overview issue ideally for a 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..
    • Tracking: Tactical breakdown of efforts across the codebase and/or tied to Overview issues.
    • Overview: Comprehensive, high level view of an area of focus often with multiple tracking issues.

    Let’s keep iterating

    This system isn’t perfect but, just like with WordPress itself, it’s an iteration and you can expect more to come. This will be focused on for the WordPress 6.6 cycle on the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Editor side and likely iterated upon once more after going through a full cycle with a more tightened workflow. If done well, very little extra work should be created for contributors and those who want to contribute or follow along the efforts can do so with greater ease. Ultimately, communication around what’s gone into a release happens already and this just seeks to formalize where it happens with clearly high level labels and norms within them. 

    Thank you to @richtabor and @priethor for reviewing this post. 

    #core-editor, #gutenberg

    Sarah Norris 1:28 am on March 27, 2024
    Tags: ,   

    Agenda, Dev Chat, Wednesday March 27, 2024

    The next WordPress Developers Chat will take place on  Wednesday March 27, 2024 at 20:00 UTC in the core channel on Make WordPress Slack.

    The live meeting will focus on the discussion for updates on 6.5, and have an open floor section.

    Additional items will be referred to in the various curated agenda sections, as below. If you have ticketticket Created for both bug reports and feature development on the bug tracker. requests for help, please do continue to post details in the comments section at the end of this agenda.

    Announcements

    WordPress 6.5 was scheduled for release on March 26, 2024, however, the release has now been rescheduled for April 2, 2024. Thanks to everyone involved in the related discussions around delaying the release by one week.

    Forthcoming releases

    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.5

    Updates from the release squad can be shared in the Dev Chat.

    Please continue to test the 6.5 release. See this list of key features to test, which was published alongside WP 6.5 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. 3.

    Next 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/ release: 18.0

    Gutenberg 18.0 is scheduled for release on March 27 and will include these issues.

    Discussions

    This week the discussion will focus on any priority topics that need to be raised before the launch of WordPress 6.5.

    Proposed topics

    • Are there any priority topics needed for discussion for WordPress 6.5 release preparations?
    • Follow-up for the release squad for 6.6

    Feel free to suggest additional topics related to this release in the comments.

    Highlighted posts

    CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Editor Updates

    Props to @annezazu for putting together these updates.

    Tickets for assistance

    Tickets for 6.5 will be prioritized.
    Please include detail of tickets / PR and the links into comments, and if you intend to be available during the meeting if there are any questions or will be async.

    Open floor

    Items for this can be shared in the comments.

    Props to @joemcgill for reviewing.

    #agenda, #dev-chat

    Emily Clarke 4:55 pm on March 26, 2024
    Tags: , , ,   

    Performance Chat Summary: 26 March 2024

    Meeting agenda here and the full chat log is available beginning here on Slack.

    Announcements

    • Welcome to our new members of #core-performance
    • WordPress 6.5 delayed (see blog post):
      • RCrelease candidate 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). 4 will be March 28
      • Release April 2
    • Performance Team have launched two new plugins
      • Optimization Detective 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
      • Embed Optimizer plugin
    • Reminder on timezone difference for this week, this chat will remain at 16:00 UTC and then shift to 15:00 UTC from April 2, 2024

    Priority Items

    Structure:

    • WordPress performance TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets
      • Current release
      • Future release
    • Performance Lab plugin (and other performance plugins)
    • Active priority projects
      • INP research opportunities
      • Improve template loading

    WordPress Performance Trac Tickets

    • For WordPress 6.5:
      • @flixos90 Nothing concrete, though since part of the reason for the release delay is changes to the Font APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways., we should probably keep an eye on that it doesn’t regress performance. As far as I understand the scope of the changes, it shouldn’t… but still worth staying on top of
    • For Future Releases:
      • We already have 14 open items in the 6.6 milestone
      • @flixos90 update on #42441 (enhancing autoload API and disable autoload for large options) – The PR has two approvals and looks excellent to me, so I’ve marked the ticketticket Created for both bug reports and feature development on the bug tracker. for commit
        • Going to wait for a few more days to see if any additional feedback comes in, but generally plan to commit this next week so that we can get a lot of testing during the 6.6 release cycle

    Performance Lab Plugin (and other Performance Plugins)

    Active Priority Projects

      Improve template loading

      INP research opportunities

      • @adamsilverstein As promised, I have collected the results of my INP research and am sharing now in this summary doc (along with a linked spreadsheet with all the data). If you want access to the colab and queries, please request it directly in the colab.
        • The summary doc Analysis section highlights some notable data for both coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and plugins/themes (with action items) that will be worth investigating further. Since there is a ton to absorb there, I think its best to leave comments/questions on the doc itself so we can discuss async, and maybe we can discuss further at a subsequent meeting.

      Open Floor

      • @pbearne one ticket from the old tickets https://core.trac.wordpress.org/ticket/29717 might worth looking at
      • @joemcgill We’ve traditionally done a post following a 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. which gives an overview of the performance characteristics of that release. I was planning to draft one for 6.5 once we can take a final set of benchmarks, but I’m assuming that we’re going to end with similar metrics to what we’ve been seeing in the last several RCs, since we’ve not had any new improvements or regressions. I’ll also include details about the editor improvements, but that doesn’t effect any of the CWV metrics we’ve been focusing on. I’d appreciate any thoughts folks have about how to communicate the performance of 6.5 clearly, while accurately reflecting that our benchmarks do NOT show an improvement over the previous release.
      • REMINDER: This meeting will switch to 15:00 UTC from April 2 (next week) onwards

      Our next chat will be held on Tuesday, April 2, 2024 at 15:00 UTC in the #core-performance channel in Slack.

      #core-performance, #performance, #performance-chat, #summary

      Emily Clarke 1:07 pm on March 25, 2024
      Tags: , , ,   

      Performance Chat Agenda: 26 March 2024

      Here is the agenda for this week’s performance team meeting scheduled for Mar 26, 2024 at 16:00 UTC.

      • Announcements
        • Welcome to our new members of #core-performance
        • WordPress 6.5 delayed:
          • RCrelease candidate 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). 4 will be March 28
          • Release April 2
        • Performance Team have launched the new Optimization Detective plugin
        • Reminder on timezone difference for this week, this chat will remain at 16:00 UTC and then shift to 15:00 UTC from April 2, 2024
      • Priority items
        • WordPress performance TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets
          • Current release
          • Future release
        • Performance Lab 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 (and other performance plugins)
        • Active priority projects
          • INP research opportunities
          • Improve template loading
          • Plugin checker
      • Open floor

      If you have any topics you’d like to add to this agenda, please add them in the comments below.

      This meeting happens in the #core-performance channel. To join the meeting, you’ll need an account on the Make WordPress Slack.

      #agenda, #meeting, #performance, #performance-chat

      Akshaya Rane 11:16 am on March 22, 2024
      Tags: , ,   

      WordPress 6.5 Release Day Process

      UPDATE: Following Font Library-related discussion the release party has been rescheduled to April 2nd, 2024.

      Preparation for the WordPress 6.5 release is underway.

      This post shares the release process, including the timeline and how you can help.

      Release Timeline Overview

      Dry Run

      The Dry Run is a key event as a final walk-through for the final release. As noted above, this is scheduled on April 1, 2024 in the #core Slack channel.

      What happens usually during the dry run?

      • Bug reports are reviewed to determine if any are critical to warrant another RCrelease candidate 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). (release candidaterelease candidate 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).).
      • Checks and any necessary updates are made in the src/wp-adminadmin (and super admin)/includes/update-core.php file.
      • Pre-release scripts are run to ensure test suites, coding standards, and other automated checks pass.

      If the results are acceptable, the release will go into a 24-hour code freeze period.

      24-Hour Code Freeze 

      After the dry run and before the release party starts, a mandatory 24-hour code freeze goes into effect.

      What does this mean? No source code for 6.5.0 (i.e., in the 6.5 branchbranch 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".) can be changed during these 24 hours.

      What happens if a critical 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. is reported during this period? The release squad will meet with committers and maintainers to determine if the issue is a blockerblocker A bug which is so severe that it blocks a release..

      • If yes, another RC release happens, and the release process restarts (meaning the dry run is repeated, and then the 24-hour code freeze clock restarts).
      • If not, then the bug is targeted for 6.5.1.

      The Release Party 📅

      The WordPress 6.5 Release Party will start on Tuesday, April 2, 2024 at 18:00 UTC in the  #core Slack channel.

      The release party walks through the steps in the Major Version Release process for anyone who wants to follow along.

      Please note releasing a major version requires more time than releasing a 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. or release candidate. There are more steps in the process. If any last-minute issues need addressing, more time will be needed.

      How You Can Help

      A key part of the release process is checking that the ZIP packages work on all the available server configurations. If you have some of the less commonly used servers available for testing (IIS, in particular), that would be super helpful. Servers running older versions of PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher and MySQLMySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. https://www.mysql.com/. will also need testing.

      You can start this early by running the WordPress 6.5 RC4 packages, which are built using the same method as the final packages.

      During the release party, options will be provided on how to help test the release package.

      Tips on What to Test

      In particular, testing the following types of installs and updates would be much appreciated:

      • Does a new WordPress install work correctly? This includes running through the manual install process, as well as 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/ or one-click installers.
      • Test upgrading from 4.0.38, 4.9.22, 5.8.6, 5.9.5, 6.0.3, 6.2.2, 6.3.0, 6.4.0, 6.4.1, 6.4.2 and 6.5 RC3, as well as any other versions possible.
      • Remove the wp-config.php file and test a fresh install.
      • Test single site and multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site/networknetwork (versus site, blog) (both subdirectory and subdomain) installations.
      • Does it upgrade correctly? Are the files listed in $_old_files removed when you upgrade?
      • Does multisite upgrade properly?

      Testing the following user flows on both desktop and mobile would be great to validate each function as expected:

      • Publish a post, including a variety of different blocks.
      • Comment on the post.
      • Install a new 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/theme, or upgrade an existing one.
      • Change the site language.
      • If you’re a plugin developer, or if there are complex plugins you depend upon, test that they’re working correctly.

      For a more in-depth list of what features to test, make sure to check the Help Test WordPress 6.5 post.

      Thanks to @davidbaumwald, @priethor for the peer review.

      #6-5, #core, #release-process

      Sarah Norris 7:30 pm on March 21, 2024
      Tags: , ,   

      Summary, Dev Chat, March 20, 2024

      Start of the meeting in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/., facilitated by @joemcgill.

      Announcements

      WordPress 6.5 RC 3 was released on March 19, 2024, and Gutenberg 17.9 was released on March 13. Please continue to help test and provide feedback.

      Forthcoming Releases

      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.5

      We are in the final week before WordPress 6.5 is scheduled to be released, with a Dry Run scheduled for next Monday, March 25, and the release scheduled for Tuesday, March 26.

      @swissspidy and @sergeybiryukov will both be around to help during the Dry Run.

      Please continue to test the 6.5 release. See this list of key features to test, which was published alongside WP 6.5 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. 3.

      Next 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/ release: 18.0

      Gutenberg 18.0 is scheduled for release on March 27 and will include these issues.

      Discussion

      Given that this was the last dev chat before the 6.5 release, we concentrated on discussing any final decisions, blockers, etc.

      @swissspidy suggested starting with the Font Library:

      From what we’ve seen so far, it seems that adding such a fallback logic appears to be more complex than originally anticipated and that it’s not feasible to land this in time for 6.5. Adding a silent fourth RCrelease candidate 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). solely for that would be too risky.
      So for 6.5 we might want to consider:
      1. Leave the current situation as-is (fonts go to `wp-content/fonts`, no fallback)
      2. Point people to plugins such as Fonts to Uploads and the dev-note explaining how to change the upload location.
      3. Re-evaluate fallback logic for 6.5.1 or 6.6 if needed, also considering potential folders in the future (patterns, templates, AI models, etc.)

      We discussed how the fallback logic is proving to be more complicated than expected and will present a future maintenance burden and potential for bugs that aren’t worth the risk of rushing to land a fix. We mentioned alternative options, including delaying the release and removing the Font Library.

      The suggestion from release leads and people familiar with the latest state of the Font Library was that it is in a good enough shape to include, and that the difficulty is in the implementation of the potential automatic fallback and not in implementing the feature itself. Therefore, the plan following the conversation was that the feature will be shipped without the fallback logic in place.

      Based on this, the following actions should be taken:

      1. A post on make/coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. to communicate the decision — @peterwilsoncc offered to start on a draft
      2. Update the docs with a pointer to the 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 — @flexseth offered to help update docs (@mikachan also happy to help here)
      3. Update https://wordpress.org/plugins/fonts-to-uploads/ to a Canonical plugin with maintenance by WP Contributors/WP.org with source moved under the WP org on 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/ so that it’s a shared responsibility
      4. Once the post outlining the decision to change to the the fallback directory behavior is posted, we should inform #forums, along with a request from them to be on the lookout for issues with the lack of a default Font Library fallback — @jorbin offered to help with this

      Also related to the Font Library, @grantmkin noted that there is a wordpress-importer PR that needs review if someone has expertise and availability.

      Highlighted posts

      The full list of posts from the last week in Core can be read on the agenda at this link.

      Open floor

      There were two issues raised on the agenda:

      1. Would the fix for plugin zip file uploads be included in 6.5?
        • Yes, the fix is merged into 6.5
      2. Will we have an extra RC, since there are some unresolved Font Library tasks?
        • There is currently no extra RC release planned

      When discussing whether we needed another RC, the suggestion was to release an RC for any necessary Font Library changes (or any additional needed code changes) later this week, while the $_old_files change and theme bumps are handled during the Dry Run without publishing an extra RC.

      @joemcgill closed the chat by suggesting that if the purpose of an RC is to allow time for more testing, to not make it silent, and encourage the release leads to finalize a plan. Coordination about an extra RC continued following the meeting in the release leads channel.

      Props to @joemcgill for reviewing.

      #6-5, #dev-chat, #summary