The Joomla 3.4 announcement introduces a new release strategy that replaces the previous Long Term Support (LTS) and Short Term Support (STS) concepts along with the “.5” numbering convention. The new Joomla! Development Strategy blog followed by the FAQ's for Joomla's Improved Release Cycle attempt to shed some light on this new release strategy.
This brief compares old and new approach, outlines differences and expected (potential) impact on Joomla stakeholders.
The way things were
Joomla development / release strategy was based on Time-based release-cycles that provided the following characteristics:
-
Release Schedule and Numbering
Previously, the release-schedule was 6 months-spaced minor "STS" (short-term support) releases (3.0, 3.1, 3.2, 3.3), followed 6 months later by a minor "LTS" (long term support) "x.5.0" release (e.g. 3.5.0), followed by a major "x+1.0.0" release (e.g. 4.0.0). LTS versions were numbered as "x.5.0". -
Maintenance Periods
LTS releases were maintained for at least 27 months, and more exactly until 6 months after the next LTS release (4.5.0) release, while STS releases were maintained for 1 month after the next STS release. -
Compatibility and New Features
STS releases introduced new non-breaking features, while LTS releases did not introduce new features. New major releases could introduce new features which were breaking backwards compatibility for extensions.
The way things will be going forward
Strategy is now based on features-based release-cycles and Semantic Versioning with the following characteristics:
-
Release Schedule and Numbering
From now on, each major "x.0.0" or minor "x.y.0" release is considered as what was previously known as a "LTS" release. No more "x.5" LTS numbering. Minor releases are also considered as maintenance releases with an added focus on quality and (non-breaking) backwards compatibility. There are no timed releases anymore ("it's ready when it's ready"). -
Maintenance Periods
Each major "x.0.0" marks the beginning of a X-series set that has an expected lifespan of at least 4 years. Every minor "x.y.0" release that happens N months after the 2 first years of active development of a major release will add N months to the expected lifespan of the X-series (making it 4 years plus N months). Theoretically, the lifespan of a series may be extended indefinitely as long as new minor releases are released. -
Compatibility and New Features
Minor releases (e.g. 3.4.0) may introduce new non-breaking features. Major releases (e.g. 4.0.0) introduce new features that may break backwards-compatibility.
What these changes mean for you
Here is a real-life Joomla 3 series example:
-
since Joomla 3.0 was released on 27/09/2012 initial end of life (eol) date for the 3 series is set to 27/09/2016 (4 years after its initial release)
-
every Joomla 3.x minor release that takes place after 27/09/2014 will extend the initial expected eol date
-
as Joomla 3.3 and 3.4 are expected to be released on 22/04/2014 and 15/07/2014 (both before 27/09/2014) they will not influence the Joomla 3 series eol date
-
assuming that a Joomla 3.5 is released on 01/01/2015 this will automatically extend the Joomla 3 series eol to 01/01/2017
The new strategy will impact future releases in the following ways:
-
Release Scheduling and Numbering
Clear [major].[minor].[maintenance] semantic numbering without the sometimes confusing "x.5.0" LTS numbering. Releases occur when they are ready instead of "forced" time-released. -
Maintenance Periods
Every release is a quality and stability release (and should be viewed as what was previously known as a LTS release). Each new major release gets an expected lifespan period of at least 4 years. -
Compatibility and New Features
Minor releases are more compatibility aware without excluding new non breaking features. There is no expected significant change for compatibility-breaks for Major versions. -
Development and Quality
The new strategy Facilitates smoother development and better code quality in terms of bugs and compatibility. “It's ready when it's ready”: No more features-rush (“no worries, if it doesn't reach this minor release, it will go into next one”) and lack of time for squashing bugs due to firm release dates. It produces smoother release-cycles, and no period without new features of 1-year time between the last STS, during LTS development and new major release. It also frees up a bit major releases from backwards-compatibility constraints.
Conclusions and future impact
Many articles discuss the benefits and pitfalls of each approach, such examples are:
We believe the Joomla! Project and its users will benefit from the new, more flexible, approach with longer maintenance periods, better quality and compatibility, clearer version numbers, continuous innovation without the “innovative features freeze” between the last STS release and the next major release.
Overall this strategy change will maintain Joomla as a major community-driven open-source CMS and should unleash its development community helping it introduce new innovative features. Joomla! is here to stay and has a bright future.
Of course as with any strategy, no matter how innovative and flexible it is, the end result depends entirely on the participation and implementation of the relevant community as a whole.