Tag Archives: release-process

Tonya Mork 4:42 pm on January 20, 2022
Tags: , , release-process   

WordPress 5.9 Release Day Process

Updated: 24 Jan 2022

Preparation for WordPress 5.9 final release is underway. This post shares the release process, including the timeline and how you can help.

Release Timeline

The current plan is:

Dry Run

Update: The Dry Run was successfully completed ✅ See the process in the #core Slack channel.

The Dry Run is a key event to determine readiness for the final release. As noted above, the current plan is to start it on 2022-01-24 15:00. You are invited to observe and/or participate. It’ll happen in the #core Slack channel.

What happens during the dry run?

  • Review 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. reports 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 updates are done in the src/wp-admin/includes/update-core.php file.
  • Pre-release scripts are run to ensure test suites, coding standards, and checks pass.

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

24 Hour Code Freeze

Update: The 24-hour code freeze is in effect 🕜

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

What does this mean? No source code for 5.9.0 (i.e., in the 5.9 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 bug 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 no, then the bug is targeted for 5.9.1.

The Release Party 🎉

WooHoo, you’ve made it to release day 🎉!

As noted above, the current plan is to start the release party on 2022-01-25 19:20. You are invited to observe and/or participate. It’ll happen 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 there are any last-minute issues that 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 different server configurations available. 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 even start this early, by running the WordPress 5.9 RC3 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.33, 4.9.18, 5.7.2, 5.8.3, and 5.9 RC 3, as well as any other versions possible.
  • Remove 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) installs.
  • 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.

Props to @jeffpaul for peer review and @marybaum, @webcommsat, and @cbringmann for editing.

#5-9, #release-process

Jeffrey Paul 9:51 am on July 19, 2021
Tags: , , release-process   

WordPress 5.8 Release Day Process

We’re less than 24 hours away from WordPress 5.8! If you would like to help with the final steps of the release, here is how you can join in.

The current plan is to start the release process at Tuesday, July 20, 2021 1500 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.

The major version release process can take a bit more time than the Betas or Release Candidates do, particularly if we run into any last minute issues that need to be addressed.

The Release Process

We will be working through the Major Version Release process for anyone who wants to follow along. Earlier today the pre-final release dry run was coordinated in #core (Slack archive).

How You Can Help

A key part of the release process is checking that the ZIP packages work on all the different server configurations available. 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.

There are two ways to help test the package:

  • Use 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/ to test: wp core update https://wordpress.org/wordpress-5.8.zip
  • Directly download the 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./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). version (e.g., https://wordpress.org/wordpress-5.8.zip)

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-CLI or one-click installers.
  • Test upgrading from 4.0.33, 4.9.18, 5.7.2, and 5.8 RC 4 as well as any other versions possible
  • Remove wp-config.php file and test 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) installs
  • Does it upgrade correctly? Are the files listed in $_old_files removed when you upgrade?
  • Does Multisite upgrade properly?

Finally the following user flows, on desktop and mobile, would be great to validate work 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.

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

#5-8, #release-process

Francesca Marano 10:33 am on October 29, 2020
Tags: release-process   

Discussion: align the WordPress release cycle with the industry standard

The standard software release life cycle hasn’t really changed much since the beginning of programming.

WordPress, for the most part, attempts to closely follow the established pattern, with the exception of what can get committed in 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..

For the past year, there have been conversations in Slack and in the blog about the release cycle. Here is a recap post with a call for feedback.

The WordPress Release Cycle – Today

Each release cycle spans multiple weeks and different phases.

Phase 1: Planning and securing team leads

This period starts as soon as a 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". is created for the previous version (the code is copied from “trunktrunk 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.” to a new “branch” in the repository), which means that two major WordPress versions are worked on at the same time. For example, active development on WordPress 5.6 started about two weeks prior to the WordPress 5.5 release. 

During this phase, the release leadRelease Lead The community member ultimately responsible for the Release. discusses features for the next release of WordPress. Contributors get involved with that discussion. The release lead will identify focus leads for each of the features. Information is gathered from different sources to put together a scope and schedule, followed by a kickoff post.

Phase 2: Development work begins

The kick-off post (see an example from WordPress 5.6) marks the beginning of structured, organised work towards Beta. The length of the period might vary, based on what was achieved during the period before the announcement and what is planned for the release.

Focus leads assemble teams and work on their assigned features. Regular chats are scheduled to ensure the development keeps moving forward.

Phase 3: Beta 

Betas are released and beta-testers are asked to start reporting bugs. No more commits for new enhancements or feature requests are allowed for the rest of the release.

WordPress generally plans for multiple betas.

Phase 4: 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).

In WordPress, release candidates are considered code complete, so no new source code is introduced unless it is to fix regressions or serious bugs discovered during 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).. Even then, every commit during this phase needs sign-off from two CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. committers.

This means hard-freeze on all strings, including those in the About page. It is important to do so to allow the Polyglots team to have enough time to translate it.

During this phase, a new branch will be created thus starting a new release cycle while we are finishing the current.

Phase 5: Launch

This is the final version that is launched and available for update through the dashboard or via download.

How to align the WordPress release cycle with the industry standard

With this in mind, here are the changes that could be put in place to align the WordPress release cycle with the traditional software release cycle.

Phase 1: Preliminary Planning

Stays the same in terms of tasks. Can be renamed “Preliminary planning” for brevity and clarity.

Phase 2: Alpha

While traditionally priority has been given to enhancements and new features, it would be beneficial to address also all 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.-fixes that are planned for inclusion in the version of WordPress people are working on. 

Changes

  • Rename to “Alpha” for brevity and clarity.
  • All the bugs that people want to see fixed in the next release need to be addressed in this phase and not postponed to Beta.

Phase 3: Beta

This is where WordPress differs from the standard. 

Historically, 

Beta phase generally begins when the software is feature complete but likely to contain a number of known or unknown bugs.

Wikipedia

Beta is essentially for testing and fixing bugs discovered after the release of Beta 1 (so bugs introduced in Alpha).

Changes

  • Hard freeze on Beta (ETA code and strings), except for the About page.
  • The tickets that were not committed and are still on the milestone at the time of Beta 1 release party, should be moved to a later release, even if they are bugfixes.

Benefits

  • Virtually no new bugs are introduced during Beta. This means focus on testing and subsequent bug fixing. 
  • More efforts and resources could be allocated to beta-testing. 
  • Beta and RC could be and should be fewer and shorter. This is because we address only bug fixes that emerged during beta testing. 
  • Aligning to the norm makes it easier for new people to join since they are used to a certain procedure and they won’t be confused by the way releases are done in WordPress.

Phase 4: Release Candidate

No changes

Phase 5: General Release

Stays the same in terms of tasks. Can be renamed to “General Release” for clarity.

It’s your turn!

Disclaimer: even if everyone is on board, nothing will change for the current release cycle, WordPress 5.6, because we are already in Beta. 

Please post feedback on:

  1. Name changes for Phase 1, 2 and 5
  2. All bug-fixes milestoned to be addressed in Alpha and not postponed to Beta 
  3. Reserving Beta for testing and fixing bugs discovered by testing

Deadline: November 17th, the date scheduled for Release Candidate 1 of WordPress 5.6 and, potentially, when trunk gets branched for 5.7. Extended to December 2nd, to give people more time to respond.

Thanks!

Props @azaozz, @davidbaumwald, @joostdevalk and @ireneyoast for providing historical and technical knowledge on release cycle procedures, and @chanthaboune and @jeffpaul for editing suggestions.

#release-process

Francesca Marano 6:28 pm on March 18, 2020
Tags: release-process   

Release Model Working Group Chat Postponed

Sorry for the very late notice, but tonight @amykamala and I are not able to host the chat.

However, if you are interested in working on it async, here are some issues that need help.

See you on April 1t (no joke!)

#release-process

Amy Kamala 6:27 am on February 26, 2020
Tags: , , release-process   

Release Model Working Group Chat Summary: February 19th, 2020

This is the Summary of the Release Model Working Group Chat in #core on Slack at 20:00 UTC!

Folks are welcome to check out the agenda and Slack archive for this week’s meeting. Here is a recap of the last meeting, as well.

Thank you to @mikeschroder for doing the peer review on this summary!

This week a kan ban project board was introduced with new 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/ issues created!

@noisysocks broke down some of the ‘development’ phase of the pre-release cycle into individual issues for each critical step. 

A few of the issues have been assigned to contributors and more volunteers are welcome! Workflow is being broken down amongst team members as follows:

  • @marybaum is covering the kick off release video and alpha phase announcement steps, and mentioned that the alpha kick off announcement would happen weeks to months earlier than the video. @desrosj pointed out that the last release video was for 5.0 Bebo.
  • @marybaum may also put together an alpha-beta launch brief.
  • @noisysocks is taking the lead on examining the process of compiling dev notes. @audrasjb volunteered to help, and folks mentioned that the 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. for 5.4 are being put together right now. @desrosj brought up that @jorbin, @jeffpaul, and @desrosj have facilitated 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. for recent releases and can assist with this item, too.
  • @francina is working on collecting information from component maintainers.
  • @clorith is researching each team’s role in a release.
  • @hristo-sg and @amykamala are evaluating the process of testing involved in a release with the goal of identifying areas that could be further automated or streamlined.

@noisysocks mentioned that some conversations have already lead to ideas for recommendations!

Next Meeting

Meetings for the Working Group will take place on the first and third Wednesday of the month at Wednesday March 4, 2020 at 08:00 UTC and Wednesday March 4, 2020 at 20:00 UTC. Hope to see you there!

#meeting-notes, #release-process

Amy Kamala 7:16 pm on February 19, 2020
Tags: release-process   

Agenda: Release Model Working Group – February 19, 2020

Here is the agenda of the chat happening today, Wednesday, February 19, 2020, at 08:00 PM UTC.

Some progress has been made following last week’s meeting! This week, we’ll discuss:

  • Kan Ban Board and Project for the Release Model Working Group
  • New issues/tickets added to the Github Repo
  • Issues/tickets that need volunteers

Looking forward to our chat!

#release-process

Amy Kamala 11:55 pm on February 6, 2020
Tags: , release-process   

Release Model Working Group Chat Summary: February 5th, 2020

Here is the Summary of the second Release Model Working Group Chat in #core on Slack at 20:00 UTC!

Thank you to @sergeybiryukov for the peer review on these meeting notes!

The Release Model Working Group was kicked off last week, with these goals in mind: 

  • Evaluate the technical changes needed to speed up the release process.
  • Evaluate if those changes are doable with the existing resources and tools.
  • Produce factual, objective documentation outlining the group’s findings.

Folks are welcome to self-assign areas of interest, which are outlined in this spreadsheet.

A GitHub repo has been created for the project, and there are a few open issues for the group to get started with. Here are some areas the group will focus on:

  • Existing documentation on the release cycle, with an emphasis on out of date items, items contingent on other steps, items that should be tied to specific timeframes and items that can be automated. As next steps, Issue 2 and Issue 4 for reviewing documentation can be broken down into different sections.
  • The internal release process. Issue 3 was created to get that started.
  • During the chat @marybaum opened an issue proposing a formal announcement of the alpha process at 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"..
  • Testing as it relates to the release cycle.
  • Security as it relates to the release cycle.
  • How each team is involved in the release cycle, with @clorith leading the charge on that one.
  • New Contributor Onboarding.
  • @francina, @audrasjb, @marybaum are handling the pre-kick-off phase.

Next Meeting

Meetings for the working group will take place on the first and third Wednesday of the month at 08:00 UTC and 20:00 UTC. The next meeting is on Wednesday, February 19th, 2020. Hope to see you there!

 #release-process #meeting-notes

#release-process

Amy Kamala 7:42 pm on February 5, 2020
Tags: release-process   

Agenda: Release Model Working Group – February 5, 2020

Following last week’s kickoff meeting, here is the agenda of the chat happening later today: Wednesday, February 5, 2020, at 08:00 PM UTC.

The group works on a self-organized basis, but there are some things to agree upon all together as per last week chat’s recap:

  • Schedule planning regarding adoption of tasks
  • Next Steps towards research and documentation in 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/

Thanks!

#release-process
Francesca Marano 2:08 pm on January 31, 2020
Tags: release-process   

Chat recap: Release Model Working Group – January 29, 2020

Today the kickoff meeting for the group happened at in the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. channel, based on this agenda. You can read the whole chat in Slack.

This recap is not in the order things were said, but in the order that (IMHO of course 🙂 ) makes more sense to see the project as a whole.

The Situation Now

As provided by @chanthaboune (thanks!)

  • We have some handbook documentation that has most of the steps plus some out of date things
  • We are lacking full documentation of the interior processes (knowing that some are irresponsible to publish in their entirety).
  • We are also lacking which steps are
    1. out of date
    2. contingent on other steps
    3. should be tied to particular timeframes
    4. automatable

Short introduction of the scope of the group

The increase of the cadence is not a foregone conclusion. The working group is here to research and document.

By documenting the existing release process, the group can:

  • Evaluate the technical changes needed to speed up the release process
  • Evaluate if those changes are doable with the existing resources and tools

The end result will be a few factual, non-opinionated documents which outline the above.

So! What is the group actually working on?

This point sparked a lively conversation! After a bit of back and forth, the group decided to adopt an existing document, put together by @chanthaboune over two years (thanks, again!): it divides the release into phases that group types of work needed.

Some of the attendees have already expresses interest in some specific areas:

  • @aaroncampbell is interested in helping document out the jobs of, and needs/struggles of, the security team.
  • @francina and @audrasjb are interested in the pre-kickoff phase:
    • Talk to leads, committers, and component maintainers.
    • Set a scope
    • Set a schedule
    • Etc…
  • @pandjarov (who wasn’t present, so @francina represented his commitment) is ready to work on E2E tests. These have been identified as a must-have even if the release model doesn’t change.
  • @amykamala is available for general project management and help with facilitating/coordinating E2E testing improvements with the hosting team + document.
  • @clorith can track down all the various teams touched by a release.
  • @marybaum is interested in the human side: making sure we have enough people at any stage and make sure there are backups.

Action item: go over the Google Spreadsheet, see if there is a topic that you are familiar with and it sparks joy. If yes, please see below and start working on it based on the workflow suggested.

Tools

We will be using 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/.

A repo has been created and we can use the Project feature to keep track of the process.

The workflow will be (at least for now, so we can test it):

  1. Create an issue for the topic researched.
  2. All comments, research, findings will be added as comments. This will help keep the discussion focused.
  3. Once the research is ready, recap and move it to a document

Proposed meeting times

  • 1st and 3rd Wednesday, at 20:00 UTC (alternating with the New Contributors chat and back to back with Dev Chat)
  • 1st and 3rd Wednesday, at 8:00 UTC for APAC

Action item: times to be confirmed by group members.

All right, that’s a lot of info: what is next?

  1. Please confirm in the comments that the proposed meeting times are ok and if you are available to facilitate the chats.
  2. @francina – I will create the first issue on GitHub as an example. Done.
  3. Everyone interested: adopt a topic and get working 🙂 PingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” me if you need to be added to the repo. Use the first issue as an example if you wish.

Thank you for making WordPress, now let’s get working!

#release-process

Francesca Marano 5:12 pm on January 29, 2020
Tags: release-process   

Agenda: Release Model Working Group – January 29, 2020

Here is the agenda for the the kickoff meeting happening later today: Wednesday, January 29, 2020, at 07:00 PM UTC.

More information about the working group in the previous post.

  1. Short introduction of the scope of the group
  2. Self-assign areas of interest
  3. Decide on tools to track process
  4. Decide on times of meetings

#release-process