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?
westi on wordpress 