Chapter 3: Understanding Development and Release Cycles
In This Chapter
Delving into WordPress release cycles
Exploring betas, release candidates, and final release versions
Navigating WordPress release archives
Tracking WordPress development
Using bleeding-edge builds
If you’re planning to dip your toe into the WordPress waters (or you’ve already dived in and gotten completely wet), the WordPress platform’s development cycle is really good to know about and understand because it affects every WordPress user on a regular basis.
WordPress and its features form the foundation of your website. WordPress is a low-maintenance way to publish content on the web, and the software is free in terms of monetary cost. However, WordPress isn’t 100 percent maintenance free, and part of maintenance is ensuring that your WordPress software is up-to-date to keep your website secure and safe.
This chapter explains the development cycle for the WordPress platform and shows you how you can stay up-to-date and informed about what’s going on. This chapter also gives you information on WordPress release cycles and shows you how you can track ongoing WordPress development on your own.
Discovering WordPress Release Cycles
Book I, Chapter 2 introduces you to the concept of open source software and discusses how the WordPress development community is primarily volunteer developers who donate their time and talents to the WordPress platform. The development of new WordPress releases is a collaborative effort, sometimes requiring contributions from more than 300 developers.
The public schedule for WordPress updates is, roughly, one new release every 120 days. As a user, you can expect a new release of the WordPress software about three times per year. The WordPress development team sticks to that schedule closely, with exceptions only here and there. When they make exceptions to the 120-day rule, they usually make a public announcement about it so that you know what to expect and when to expect it.
Mostly, interruptions to the 120-day schedule occur because the development of WordPress is primarily on a volunteer basis. A few developers — employees of Automattic, the company behind WordPress.com — are paid to develop for WordPress, but most developers are volunteers. Therefore, the progress of WordPress development depends on the developers’ schedules.
I’m confident in telling you that you can expect to update your WordPress installation at least three, if not four, times per year.
Upgrading your WordPress experience
Don’t be discouraged or frustrated by the number of times you’ll upgrade your WordPress installation. The WordPress development team is constantly striving to improve the user experience and bring exciting and fun new features to the WordPress platform. Each upgrade improves security and adds new features to enhance your (and your visitors’) experience on your website. WordPress also makes the upgrades easy to perform, which I discuss in Book II, Chapter 6.
The following list gives you some good reasons why you should upgrade your WordPress software each time a new version becomes available:
Security: When WordPress versions come and go, outdated versions are no longer supported and are vulnerable to malicious attacks and hacker attempts. Most WordPress security failures occur when you’re running an outdated version of WordPress on your website. To make sure that you’re running the most up-to-date and secure version, upgrade to the latest release as soon as you can.
New features: Major WordPress releases (I discuss the difference between major versus minor, or point, releases later in the chapter), offer great new features that are fun to use, improve your experience, and boost your efficiency and productivity. Upgrading your WordPress installation ensures that you always have access to the latest and greatest tools and features that WordPress has to offer.
Plugins and themes: Most plugin and theme developers work hard to make sure that their product is up-to-date with the latest version of WordPress. Generally, plugin and theme developers don’t worry about backwards compatibility, and they tend to ignore out-of-date versions of WordPress. To be sure that the plugins and themes you’ve chosen are current and not breaking your site, make sure that you’re using the latest version of WordPress and the latest versions of your plugins and themes. (See Book VI for information about themes, and Book VII for details about plugins.)
Understanding the cycles of a release
By the time the latest WordPress installation becomes available, that version has gone through several iterations, or versions. This section helps you understand what it takes to get the latest version to your website, and explains some of the WordPress development terminology.
The steps and terminology involved in the release of a new version of WordPress include
Alpha: This is the first developmental phase of a new version. This is typically the “idea” phase in which developers gather ideas, including ideas from users and community members. During the alpha phase, developers determine which features to include in the new release and then develop an outline and a project plan. After features are decided, developers start developing, and testers start testing until they reach a “Feature Freeze” point in the development cycle where all new features are considered complete. The development moves on to perfecting new features through user testing and bug fixes.
Beta: This phase is to fix bugs and clear any problems that testers report. Beta cycles can last up to four to six weeks, if not more. WordPress often releases several different beta versions with such names as WordPress version 3.2 Beta, WordPress version 3.2 Beta 1, and so on. The beta process continues until the development team decides that the software is ready to move into the next phase in the development cycle.
Release candidate: A version becomes a release candidate (RC) when the bugs from the beta versions are fixed and the version is nearly ready for final release. You sometimes see several release candidate iterations, referred to as RC-1, RC-2, and so on.
Final release: After a version has gone through full testing in several (hopefully all) types of environments, use cases, and user experiences, any bugs from the alpha, beta, and RC phases have been squashed, and no major bugs are being reported, the development team releases the final version of the WordPress software.
After the WordPress development team issues a final release version, they start again in the alpha phase, gearing up and preparing to go through the development cycle for the next major version.
Typically, a development cycle lasts 120 days. However, this is an approximation because any number of things can happen (from developmental problems to difficult bugs) to delay the process.
Finding WordPress release archives
WordPress keeps a historical archive of all versions it has ever released at http://wordpress.org/download/release-archive, as shown in Figure 3-1. On that page, you find releases dating back to version 0.17 from 2003.
None of the releases found on the WordPress website is safe for you to use except for the latest release in the 3.0.x series. Using an older version leaves your website open to hackers. WordPress just likes to have a recorded history of every release for posterity’s sake.
Figure 3-1: The archive of every WordPress release on record.
Major versus point releases
You may have noticed that WordPress versions are numbered. These numbers show the progress of the development of the software, but the numbers also serve a purpose and tell you something else about the version you are using. Software versioning is a method of assigning unique numbers to each version release. Generally, the two types of versioning are
Point release: Point releases usually only increase the numbered version by a decimal point or two, indicating a relatively minor release. Such releases include insignificant updates or minor bug fixes. For example, when the version number jumps from 3.4 to 3.4.1, you can be certain that the new version was released to fix existing minor bugs or to clean up the source code rather than to add new features.
Major release: A major release most often contains new features and jumps by a more seriously incremented version number. For example, WordPress going from 2.9.2 to 3.0 (release 2.9 versioned into 2.9.1 and 2.9.2 before jumping to 3.0) was considered a major release because it jumped a whole number, rather than incrementally going up another decimal point. A large jump is a sign to users that new features are included in this version, rather than just bug fixes or clean up of code. The bigger the jump in version number, the more major the release. For example, a release jumping from 3.0 to 3.5 is an indication of some major new features.
Keeping Track of WordPress Development
If you know where to look, keeping track of the WordPress development cycle is easy, especially because the WordPress development team tries to make the development process as transparent as possible. You can track updates by reading about them in various spots on the Internet and by listening to conversations between developers. If you’re so inclined, you can jump in and lend the developers a hand, too.
You have several ways to stay up-to-date on what’s going on in the world of WordPress development, including blog posts, live chats, development meetings, tracking tickets, and bug reports, just to name a few. The following list gives you a solid start on where you can go to stay informed:
WordPress Development Updates (http://make.wordpress.org/core): The WordPress development team's blog is where you can follow and keep track of the progress of the WordPress software project while it happens. (See Figure 3-2.) You find agendas, schedules, meeting minutes, and discussions surrounding the development cycles.
Figure 3-2: The WordPress development blog.
WordPress developers' chats (irc.freenode.net in #wordpress-dev): Using an Internet chat program called IRC (Internet Relay Chat), WordPress developers gather weekly to discuss a predetermined agenda of items that need to be addressed during the development cycle. You're invited to join the IRC chat room to listen in or participate if you want to. (You can download a free IRC program called mIRC from www.mirc.com for PC users or a program called Ircle from www.ircle.com for Mac users. Follow the program's user manual for instructions on how to use IRC to chat via the Internet.)
WordPress Trac (http://core.trac.wordpress.org): Here are ways to stay informed about the changes in WordPress development:
• Follow the timeline: http://core.trac.wordpress.org/timeline
• View the road map: http://core.trac.wordpress.org/roadmap
• Read reports: http://core.trac.wordpress.org/report
• Perform a search: http://core.trac.wordpress.org/search
WordPress mailing lists (http://codex.wordpress.org/Mailing_Lists): Join mailing lists focused on different aspects of WordPress development, such as bug testing, documentation, and hacking WordPress. (Specifics about mailing lists are in Book II, Chapter 4.)
Downloading Nightly Builds
WordPress development moves pretty fast. Often, changes in the WordPress software’s development cycle occur daily. While the developers are working on alpha and beta versions and release candidates, they will commit the latest core changes to the repository and make those changes available to the public to download, install, and test on individual sites. The changes are released in a full WordPress software package called a nightly build — which contains the latest core changes submitted to the project, changes that have not yet released as a full and final version.
Using nightly builds is not a safe practice for a live site. I strongly recommend creating a test environment to test the nightly builds. Many times, especially during alpha and beta phases, the core code may break and cause problems with your existing installation, so use nightly builds in a test environment only and leave your live site intact until the final release is available.
Hundreds of members of the WordPress community help in the development phases, even though they aren't developers or programmers. They help by downloading the nightly builds, testing them in various server environments, and reporting to the WordPress development team by way of Trac tickets (shown in Figure 3-3; check out http://core.trac.wordpress.org/report) any bugs and problems they find with that version of the software.
Figure 3-3: WordPress Trac tickets.
You can download the latest nightly build from the WordPress repository at http://wordpress.org/download/nightly. For information about installing WordPress, see Book II, Chapter 4.
WordPress Beta Tester (http://wordpress.org/extend/plugins/wordpress-beta-tester) is a super plugin that allows you to use the automatic upgrade tool in your WordPress Dashboard to download the latest nightly build. For information about installing and using WordPress plugins, check out Book VII, Chapter 1.
Running the latest nightly build on your website is referred to as using bleeding-edge software because it’s an untested version requiring you to take risks just to run it on your website.