Needless to say, we did not think this slow release pace and uncertain future was a great situation either for the project or the user community. So we decided to chart a course to remedy the current situation and try to prevent a similar one in the future. We made two key decisions at that meeting: adopt a "stable trunk" practice and do time-based releases.
In software version control parlance, the trunk (think tree) is the working code used for releasing versions of the program. Developers can create branches (copies of the trunk's code) to work on major changes, like adding a new feature. By working in a branch, a group of developers can make all the changes they like without affecting either the main program or other developers working in other branches. When a feature is tested and ready, the branch for that feature is merged back into trunk and becomes part of the next release.
The idea of a stable trunk is simple: a branch (think new feature) is not merged back into trunk unless it is complete and tested and ready for release. This seems simple and obvious, but in practice it can be difficult. For example, a feature might be "99%" ready "except for a few small things that we can fix later". It can be very tempting to merge it in, especially if the feature is highly desirable and the release deadline looms. It is not fun to receive the news that a feature you have worked long hours on did not make the cut-off or has not been accepted.
What are the benefits of maintaining a stable trunk? One is that multiple teams of developers can work independently on different branches with a reasonable assurance that nothing half-baked will get merged back into the trunk and break other parts of the code. This greatly reduces the likelihood that changes created by one team will cause problems for other teams. Another important benefit is this: if you have a stable trunk, you can release a version at any point in time, simply by releasing your latest trunk. This makes time-based releases possible.
Time-Based Release Cycle
As the Danish physicist Niels Bohr once said, "Prediction is very difficult, especially about the future." This certainly applies to predicting when a software feature will be ready. It's doubly true in a volunteer-driven development project like Joomla. In a company, you normally know how many person-hours you can devote to a task. With Joomla, we don't know who might work on something or how many hours or days they might have available, let alone when they might finish it. So it is impossible to accurately predict when new features will be ready for release.
On the other hand, there are great benefits to the community to have a predictable release cycle. The PLT's solution was to release on a planned time schedule, but with an important condition: there is no guarantee of when a specific feature might be released. For example, we can predict with some confidence that we will release version 3.0 in September 2012. But we will not know what new features version 3.0 will have until they have been finished and added to the code base.
STS and LTS Releases
With this background in mind, let's look at the specifics of the current Joomla release cycle. In that same 2009 meeting, the PLT decided on an ambitious goal – to release a new Joomla version every six months. Why such frequent releases? One important consideration is to motivate developers. Volunteers who contribute code to the project want to see their code or feature get used. If the time between releases is too long, we lose this motivating factor. Releasing more frequently also makes it easier to keep up with versions of software that Joomla relies on – things like PHP, MySQL, and TinyMCE. All of these programs are under constant development and change, and we need to be able to keep pace.
To make this ambitious goal work, we needed to make sure that updates are easy to do. For example, the migration from version 1.5 to version 1.6 is challenging. This is largely because there were so many changes (three years worth!) between these versions. On the other hand, the updates from version 1.6 to 1.7 and 1.7 to 2.5 have been (we hope!) relatively smooth, and we are working to make them better and more bulletproof. For example, version 2.5 introduced automatic update notification and we are about to introduce an improved update engine that will work more reliably on slower hosts.
Releasing frequent versions also means that we need to be careful about backward compatibility. For example, extensions that work with version 1.6 should also work with 1.7 and 2.5.
Even with better updates and good compatibility, the PLT recognized that a six-month release cycle is not good for many sites. That's why we also added the idea of long-term support (LTS) releases. For example, 1.6 and 1.7 were standard-term support (STS) releases, whereas 2.5 is an LTS release. This means that version 2.5 will be supported at least until the next LTS release (version 3.5) is available – currently planned for September 2013.
So the idea of STS and LTS releases is very simple. If you want cutting edge features, you should go with the STS releases – for example, 3.0 in September 2012, 3.1 in March 2013, and 3.5 in September 2013. If you want stability and can live with the 2.5 feature set, stay on 2.5 until after 3.5 is released and then update to 3.5. Same thing with version 4. Go the 4.0 / 4.1 / 4.5 path to get the latest-greatest, or wait for 4.5 to reduce the number of updates you need to do.
The choice is entirely yours. The only condition is this: if you go with an STS release (say 3.0 or 3.1), you need to understand that these have a short lifespan and that you are in effect committing to updating every six months until you get to the next LTS release (for example, 3.5). At that point, you can decide whether to stay on the STS path (and go for 4.0 / 4.1 / 4.5) or switch to the LTS path (and wait for version 4.5).
I hope this helps you understand the current release cycle. Below are some FAQ's.
Why did we skip from version 1.7 to 2.5?
In a meeting in July 2011, the PLT decided it would make things simpler if all of the LTS releases were X.5 releases (1.5, 2.5, 3.5, and so on). To get on that plan, we could either (a) call the January 2012 release 1.8 as planned and start the X.5 numbering with version 2; or (b) we could skip from 1.7 to 2.5 and have 2.5 as the next LTS release. We decided to put this to a vote in the community and the community chose to do (b). So the January 2012 release was called 2.5 and is the current LTS release.
Why is 3.0 planned for September 2012 instead of July 2012?
While going through the 2.5 release process, it was suggested that December is a difficult month for many people to work the extra time required just before a release. After a lot of discussion, it was decided to move the release months from July / January to March / September. We will continue to release on a six-month schedule, but we will make a one-time adjustment to change the release months. So version 3.0 is planned for September 2012, 3.1 for March 2013, and 3.5 for September 2013.
When will version 1.5 reach end of life?
The original plan was for version 1.5 to reach end of life in April 2012. However, a number of people have expressed the desire to see this period extended. As a practical matter, version 1.5 has not required a lot of updates over the past year, so extending the LTS period is not expected to require a lot of project time or resources. No formal announcement has been made by the PLT, but support for 1.5 will be continued past April 2012 – probably at least until September 2012.
Will the changes from 2.5 to 3.0 be bigger than the changes from 1.7 to 2.5?
In theory, the change from version 2.5 to 3.0 could be larger than the change from 1.7 to 2.5. Because all 1.7 users were expected to update to version 2.5 right away, that update had to be as seamless and easy as possible with the highest degree of backward compatibility possible. With the 2.5 to 3.0 update, the situation is different. Version 2.5 users have the option to stay with version 2.5 for the extended support period (and eventually update to version 3.5) or update to 3.0. Because the update to 3.0 is optional, there is more leeway for making changes between 2.5 and 3.0 that may require a migration or some changes in extensions.
In either case, we want to make the update as easy as possible and provide as high a degree of backward compatibility as possible. From 3.0 to 3.1 and 3.1 to 3.5, we will again work to make the updates completely seamless. However, keep in mind that we can't predict exactly what features will be ready in time for version 3.0, so we won't know for sure how big the changes are until we are closer to the release date.
Can the release cycle be changed in the future?
The current release cycle is not "written in stone" and may well be modified in the future, based on experience and community feedback. Once version 3.0 is released, we will have been through an entire cycle of STS and LTS releases. At that point, it may make sense to evaluate how it is working in practice and make any desired changes.