The Joomla Development Strategy

Written by Jeremy Wilken 8 Feb2011

There is some confusion about how Joomla is going to be maintained and further developed. To be honest, I have questions myself, and details about the strategy are somewhat outlined here http://developer.joomla.org/strategy.html, but also hasn't been updated since 1.6 was released and other comments and details around the Joomla communication lines add to the confusion over what is going to happen.

What is certain

These are the new goals of the development strategy.

• Joomla is going to attempt a shorter release cycle. This means instead of 2.5 years between releases, only 6 months.
• Every 3rd release is considered a long term support release. The other releases are standard support releases.
• Long term support means it will be supported (bugs, security, etc) until 3 months after the next long term supported release
• Standard support means this release will only be supported about 6 months, basically only until the next release.
• The trunk (a term for the place where the final Joomla code is stored) is to be always stable, so in other words the idea is to always have an installable version of Joomla there.
• Automated tests have been added, and are required for additional updates and changes.
• Upgrade paths are planned between short term releases, and between long term releases only.

So the upcoming release cycle would be something like this (Note this is different from the Development Strategy page, as it is out of date, and is based on this thread here).

How new features will be added

The idea is that anyone making a change will make their changes in a clone of the trunk (the master copy if you will) in what is called a branch. Then that person can make all kinds of changes without breaking Joomla for others. Only after the branch is stable can it be considered to be merged into the trunk. To rephrase it all, new features are developed separately, and once they are tested to work they are included.

Development of new features lies greatly on programmers, and with the faster releases you won't see such major changes as there were in 1.0-1.5-1.6. Its simple, because 6 months is not long enough to add a ton of new things.

What is unclear

While some official statements or details are available, I haven't seen any details about plans for the future. We really only have a hazy strategy outlined across the Joomla network, that has some holes or outdated details that make it hard to understand how it will actually work out.

The strategy is not unified. So much effort and focus was put into getting 1.6 out that preparations for the new strategy (which is supposed to have begun when 1.6 was released) were not really put together. For example, we don't what goals 1.7 has, who is managing the development decisions, what the target dates actually are for the next releases, and so on.

The developer portal, which went dormant sometime between 1.5 and 1.6 release was relaunched recently. However it is mostly static content, and doesn't contain any kind of updated information. This also adds to the confusion, as it doesn't actually provide developers much insight into what is happening with Joomla. Rather it points to the mailing lists, docs, and the development strategy page.

Concerns about the cycle

I've seen a lot of concern about the changes, because developers are nervous about having to support multiple versions of Joomla that are only supported in short terms. This is certainly a concern, as it means many customers or clients will be so many different versions of Joomla that maintenance would be quite challenging. As a developer the last thing I want to do is to provide 3-4 different versions of the same program so anyone can install it depending on their version.

I'm pretty sure its going to take some time for the new cycle to really take hold, and without any clear direction 1.7 will likely be a fairly minor change. However, for stability, Joomla has to be considerate to developers and provide either backwards compatibility, or avoid making sweeping changes like we saw in 1.6. If there are framework changes in the quicker releases, it will likely drive developers mad.

One other concern I see is the tension between a project traditionally driven by a core team, that is opening doors to allow community members to contribute changes, and the community. Nobody wants to do a lot of work only to have it rejected or neglected, so without knowing that the development cycle is solid and in motion, people are less likely to spend time contributing. Without a strong leader or manager of the community driven efforts, I don't know how successful this approach can be.

Feedback

I would be more than happy to receive corrections or additions to this information. This is what I compiled to the best of my knowledge, and it would be wonderful if the most accurate information was put together here (or better yet on the developers pages).