Ideas To Improve The WordPress Release Strategy

releasethehoundsMuch has been said in recent weeks regarding WordPress upgrades, security, and responsibility. While I still think end users are the ones responsible for what happens regarding their WordPress powered site, I do think there are areas of improvement that the WordPress team should consider. The following is a list of some of my own ideas as well as a few presented by other folks involved in the conversation.

Better Release Posts – As I was doing research for this idea, I checked out the release posts between 2.7 to 2.8.4 and the one thing about all of them is that they are all different. Different in that the information presented within them are in different locations. Sometimes, the information presented is different from release to release depending on its severity or whether it’s a point release or full version release. To compound the issue, more than one person has access to write the release posts and each person has their own style of conveying the information. What I am proposing is a structured format. The format would go as follows:

[Summary containing (to the point) information regarding the release]

[Some major or minor issues resolved with a link to their ticket in trac]

[A link to all of the issues resolved in the release version. This is generally added to release posts already]

[What type of release is this? Security? Maintenance? What is the urgency level for this release?]

[Since trackbacks are the only forms of communication on the development blog, there should be an official thread in the WordPress support forum setup for each release so that we as a community have a central area to communicate and ask questions regarding the new version]

[Important information that theme/plugin authors need to know]

[Either a link that shows all of the changed files in the released version or a list of all the changed files. Also, a download link to download only the changed files which would serve as the secondary upgrade procedure if automatic upgrade is not possible or does not work]

[Last but not least, a link to download the new version]

These development blog posts should be the go-to source for all of the important information not only for site owners but for plugin and theme authors as well.

WordPress Threat Levels – This is an idea that came up in a conversation I had with someone in the community. WordPress would have three threat levels. Green, Yellow, and Red. Green would mean that upgrading wouldn’t need to be a high priority. This would probably be confined to bug fix or feature releases. Yellow would stress that upgrading sooner rather than later is recommended perhaps based on a core feature or an important fix that effects plugins or themes. Red would signify upgrade as soon as possible. Obviously, WordPress 2.8.4 would be considered Red. Using threat levels such as this might be the way to avoid constantly telling people to upgrade as soon as possible. Not all versions of WordPress require people to upgrade the minute it is available.

Email Notifications – While there are more than enough ways to find out that a new version of WordPress is available, I’ve been giving it some thought and I now believe that it would be a good idea for there to be some sort of box that I can check which would allow WordPress to send an email to the address tied to the site administrators account. Email is still the method of communication everyone uses more than anything else so it would just make sense. This would also take care of the need for the WP-Announcements email list which is not used anyways.

Dougal Campbell – The following is a large excerpt from Doug’s post on the WP-Hackers mailing list which contains his thoughts and ideas on this entire subject.

As has been pointed out time and time again, WordPress is easier than ever to keep updated. When a new version is released, a nag appears in the Dashboard. From there, it’s just a couple of clicks to upgrade. And yet, people *still* lag behind. The reasons are varied, and _mostly_ invalid (depending on your perspective). Some of it is simply “fear of breaking something”. Some of it is just simple stubbornness (“I just upgraded, I don’t want to do it again so soon!”). Some of it might be ignorance and laziness (they see the nag, but don’t look at the WordPress News blocks in the Dashboard, or go to the main site to read about it).

So, what more can we do? Not a *whole* lot, but I do have a suggestion:

You can read Dougals entire post on the WP-Hackers mailing list archive here.

What Do You Think?

So what other ideas do you have to improve the WordPress release strategy?

8

8 responses to “Ideas To Improve The WordPress Release Strategy”

  1. As a writer, I hate being asked to commit to the same format for every piece of content. Notwithstanding this, structure and consistency are important to “readers” and is probably more important for “surfers.” Anything that could be done in this area would increase uptake of information by all who encounter it.

    We can save the freeform for less strictly informational posts.

  2. A structured format is really hard to stick to in a volunteer project environment, and creates more work than is necessary.

    I feel there are only three things that could be done, which would make a huge difference:

    Use the WP-Announcements emailing list & add a link to this in the README.
    Tying announcements to WordPress itself is not practical as it relies on sites having a valid email address (not all do) and also relies on WP being able to access the install. Server permissions may make this impossible.
    Release patches, not just full downloads.Where patches can be safely applied to different versions, say so.
    Better commenting of code. If code is changed to harden security commenting it would enable users to identify where this hardening has taken place and fix their own code accordingly.

    The ideas for improving alerts in the WordPress backend are good, but don’t help those users who are running heavily customised installs, or who have locked their servers down so tight that they do not get upgrade notices, or see the dashboard feeds, or who manually apply fixes in a company-proscribed process.

  3. @realistdreamer – I see where you’re coming from, but I think the freeform could be kept in the summary of the post regarding the update. The other stuff is just easy to find links for that specific information.

    @Stephen Cronin – That is the plugin that inspired the thought that something like it should be added to the core. Some folks may disagree but I think it’s a small price to pay for one more dedicated piece of the notification puzzle.

  4. Regarding the concept of a WordPress Threat Level – This is something really hard to define.

    It is rare that a security fix is so cut and dry that you can make one of these level based statements – and if you do prepare to be shown by the ingenuity of the crackers themselves that you were wrong – it is very hard to identify all the ways in which a security bug that is fixed can be exploited!

  5. It’d be really nice to have it be clearer what’s changed.

    If it’s for security for people who have logins (and I don’t have other “users”) then I’m not worried.

    If it only modifies one file I could do that myself (and leave the RSS feed core files that I modify alone).

    It’d just be nice to know more…

  6. @westi – Yeah, in discussions with other folks regarding this idea of threat levels, it would do more harm than good if WordPress labeled the threat as minimal and yet, those who didn’t upgrade based on the threat level were compromised anyways.

    @Gary LaPointe – And that is one of the things I was trying to stress. Providing more information up front to allow responsible users such as yourself to figure out what has to be done.

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.