Category Archives: maintenance release

What should go into a WordPress maintenance release?

Now that WordPress 2.9 has hit the streets there are inevitably going to be a number of bugs which slipped through testing which people will identify and we need a good process for deciding which of these bugs should be included in an upcoming 2.9.1 release and which of them can wait until 3.0 to be fixed.

In the past I think we have included to many changes into the maintenance releases.  This has partly been due to the lack of end-user testing which has taken place during the beta phase and partly based on a drive to fix bugs sooner rather than later.  This has had the unfortunate downside of diverting the time of the core contributors, that they could have been spending on working on features for the next major release, and has meant that the release cycle has been extended to longer than we would have liked.  This means that you don’t get the cool new features like Trash as soon as you would have done.

This post is an effort to summarise my thoughts on this subject and I would welcome discussion in the comments below – hopefully we can come up with a succinct set of criteria which will may it clear to everyone what the community thinks should be included in a maintenance release and what should not.

First of all I think it is important to understand the purpose of a maintenance or point release.  To me these releases are about fixing critical bugs which affect a large percentage of end-users and disrupt their ability to use the software. They need to have a small number of changes so as to make them easy to test, lightweight to develop and to reduce the impact on the next major release. This also means that they will be easy to upgrade too and are less likely to break plugins / themes in the process so making the upgrade to them even easier and more worry free.

If we let the content of these release grow too large then we will never have the time to work on the new features for the next major release which will then mean that release takes longer to arrive and may end up with less features.  We also need to remember that every change has the risk of introducing a new bug and this is another reason we should limit the number of changes in a maintenance release.

Now we need to identify what sort of bugs fit into the category of critical bugs.  The most obvious and easiest to identify are the security bugs – fixes for these need to be available as soon as possible. Once we get beyond security bugs it can get more difficult to quantify the affect of the issue and therefore how soon a fix needs to be in the hands of the users.

The following list of criteria are my straw man proposal on this subject:

  • The issue is easily reproducible and testable.
  • The issue is severe – e.g. it makes a whole feature unusable and therefore the fix cannot wait for the next major release.
  • The issue is a regression from a previous major release – for example if an unintentional/incompatible change to an API or UI was made.
  • The issue is not just that warnings or notices appear when WP_DEBUG is enabled the area of code in question must also fail to work correctly.

What do you think?

WordPress 2.6.5 in detail

WordPress 2.6.5 has been released and includes a number of changes including one security fix, here is a list of the changes in detail:

  • Added a check for the correct post_type to blogger.editPost and blogger.deletePost (#8267).
  • Updates to update_post_meta() and delete_post_meta() to ensure they work correctly with post revisions and don’t create the meta on the revision instead of the post (#7925).
  • Protection for a very difficult to exploit XSS issue (#8291).
  • Fix for an XSS issue with the Atom and RSS feeds on some hosting setups ([9754], [9770]).

For a complete list of all the changes you can read this section of the branches/2.6 log on the WordPress bug tracker.

Note that we have skipping version 2.6.4 and jumped from 2.6.3 to 2.6.5 to avoid confusion with a fake 2.6.4 release that made the rounds.

There is not and never will be a version 2.6.4.

WordPress 2.3.3 in detail

WordPress 2.3.3 has been released and includes a number of changes including one security fix, here is a list of most of the changes in detail:

  • Reversion of the change to sent the “Sender” in wp_mail() (#5273).
  • Changes to the magic number detection for gettext file loading for better support of 64bit systems (#3780).
  • A fix in install-helper.php so that you do not get errors when included from a plugin (#5090).
  • Addition of extra capabilities checks to the xmlrpc code (#5313).
  • Fixes to the naming of some query variables used for category intersections (#5788).

For a complete list of all the changes you can read this section of the branches/2.3 log.

WordPress 2.3.2 in detail

WordPress 2.3.2 has been released and includes a number of changes including one security fix, here is a list of most of the changes in detail:

  • Performance improvements for post sanitization when raw content is required (#5325).
  • Changes to is_admin() to ensure that it is only true for admin pages thereby protecting against exposing draft posts. (#5487).
  • Suppression of database errors unless WP_DEBUG is true (#5473).
  • Check for valid database connection information during install and display and error if the install fails due to database rights (#5495).
  • Support for a custom database down page to be displayed on database connection errors (#5500).
  • Changes to make sure we are more selective in what we make clickable, this introduces different rules for different uri types ([6450]).
  • Changes to wp-mail.php to escape the error messages when displaying them to avoid a possible XSS attack (#5484).
  • Changes to ensure that the post password is only exposed by the xmlrpc method metaWeblog.getRecentPosts to users with rights to edit a post (#5535).
  • Changes to the information exposed the wp.getAuthors xmlrpc method to reduce the information exposed and add a capabilites check (#5534).
  • Addition of extra capabilites checks to xmlrpc methods ([6504]).
  • Addition of extra capabilites checks to APP server ([6508]).
  • Changes to validate_file() to improve its traversal attempt detection when running on windows ([6521]).

For a complete list of all the changes you can read this section of the branches/2.3 log.

WordPress 2.3.1 in detail

WordPress 2.3.1 has been released today and includes a number of changes including one security fix, here is a list of most of the changes in detail:

  • Improvements to the email address extraction in wp-mail.php (#5169).
  • An improvement to the link manager to ensure that only user with the manage_links capability can access the page (#4627).
  • A security fix to ensure that edit-post-rows.php cannot be directly loaded to prevent XSS attacks when register_globals is enabled ([6258]).
  • Groupings in the SQL queries used during upgrade to remove errors on duplicate entries in the old post2cat and link2cat tables (#5223).
  • The Sender is set on emails to help on hosts that limit which email addresses can send (#5007).
  • Fixes to category assignment during link import from OPML (#5107)
  • Manifest file for Windows Live Writer so as to enable tagging support (#5023).
  • Performance improvements for the Taxonomy intersection queries (#5137).
  • Exclusion of the post previews from canonicalisation (#5203)
  • Improvements to the handling of the main query to ensure it is saved when calling wp() (#5121).
  • Fix the in-line uploader so that send to editor works with a blank title (#5080).
  • Removal of the case-sensitivity on host names of wp_safe_redirect() (#5114).
  • Changes to the load order in the javascript loader to ensure that Prototype is loaded before jQuery (#5067).
  • Enforcement of the same sanitisation rules for pages as for posts (#5135)

For a complete list of all the changes you can read the branches/2.3 log.