Tag Archives: dry run

David Baumwald 8:01 pm on November 11, 2024
Tags: , dry run   

WordPress 6.7 Release Day Process

Preparation for the WordPress 6.7 release is underway.

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

Release Timeline Overview

24-Hour Code Freeze 

A mandatory 24-hour code freeze is now in effect for the 6.7 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"..

What does this mean?

No source code for 6.7.0 (i.e., in the 6.7 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 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 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.7.1.

The Release Party 📅

The WordPress 6.7 Release Party will start on Tuesday, November 12, 2024, at 20: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 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).. 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 7.4 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.7 RC5 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 various versions.
  • 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.7 post.

#6-7, #dry-run

Dominik Schilling 11:31 am on August 13, 2016
Tags: , dry run   

4.6 Release Dry Run

In preparation for the release on Tuesday, August 16 at 19:00 UTC, we’ll do a dry run on Monday, August 15 at 16:00 UTC.

The dry run will include:

  • Testing various features, including Shiny Updates, native fonts, comment/site/networknetwork (versus site, blog) queries with and without a persistent object cache
  • Generally testing the adminadmin (and super admin) and common features using a multitude of devices and browsers
  • Running our usual unit tests including the specialty groups like 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, Ajax, and external 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.
  • Doing scratch installs and upgrades from a variety of older versions
  • Triaging any bugs reported against 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., most easily found at the top of report 40
  • Updating the credits 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.
  • Reviewing the Codex release page
  • Moving about page images to the CDN
  • Checking status of translations
  • Reviewing the release post

If you’d like to help out and participate, we’d love to have you. Please come prepared to test!

#4-6, #dry-run

Kira Schroder 5:54 am on April 10, 2016
Tags: , dry run   

Release Dry Run and Window, RC2 and String Freeze

Hey everyone!

The WordPress 4.5 release proceedings will start at April 12, 2016 at 0900 PDT, with the expectation of release within 2-3 hours of that meeting time. This time allows a decent margin before 5pm EDT (April 12, 2016 at 1400 PDT), at which point a puntpunt Contributors sometimes use the verb "punt" when talking about a ticket. This means it is being pushed out to a future release. This typically occurs for lower priority tickets near the end of the release cycle that don't "make the cut." In this is colloquial usage of the word, it means to delay or equivocate. (It also describes a play in American football where a team essentially passes up on an opportunity, hoping to put themselves in a better position later to try again.) to the next day would be discussed.

To help hit that window, let’s meet the day before at April 11, 2016 at 0900 PDT for a dry run.

As a final note, WordPress 4.5 RC2 has been released, and with it, hard string freeze is upon us.

See you at the dry run, and thanks for your help in getting this far!

#4-5, #dry-run

Drew Jaynes 7:00 am on April 22, 2015
Tags: , dry run   

4.2 Release Dry Run

In preparation for a Thursday release, I’d like to do a dry run for 4.2 on Wednesday 15:00 UTC 2015.

The goal would be to complete the dry run and freeze for about a day prior to release. We’ve pushed the scheduled release date by a day due to the 4.1.2 security release that went out on Tuesday morning.

The dry run will include:

  • Testing various features, including Press This and the CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. Theme Switcher
  • Generally testing the adminadmin (and super admin) and common features using a multitude of devices and browsers, most notably mobile Safari on IOS and IE8
  • Running our usual unit tests including the specialty groups like 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 and AJAX
  • Doing scratch installs and upgrades from a variety of older versions

If we’re satisfied with the results of the dry run, then we’ll freeze. If not, we’ll discuss our options and make a contingency plan going forward.

If you’d like to help out and participate, we’d love to have you. Please come prepared to test!

#4-2, #dry-run

John Blackbourn 11:54 am on December 16, 2014
Tags: , dry run   

RC2 and release dry run

Various issues which came up over the weekend have meant that we’ve decided to delay the release of 4.1 by another 24 hours. The new target release date is Wednesday 17th December. It doesn’t serve anybody well to delay things this late in the day, but it’s essential to ensure the late fixes which have landed in the last few days are well tested.

RC2 will be packaged within the next few hours, once the recent batch of fixes in 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. are merged into the 4.1 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".. Here’s the current list of open tickets in the 4.1 milestone.

We’ll try to fit in a release dry-run meeting today at 17:00 GMT (December 16 2014 17:00 UTC) in #core, depending on the availability of the lead devs.

#4-1, #dry-run