Long Term Support (LTS) releases of CiviCRM are versions that are maintained for use by organizations for multi-year periods of time. The first official version of CiviCRM released as a LTS was version 4.4 and announced in October of 2014. 4.4 was the official LTS version until CiviCRM 4.7 was released, at which point version 4.6 was officially designated as the new LTS. The CiviCRM Core Team and several partners and contributors maintained version 4.4 and 4.6 until 2017, when Skvare and Compucorp officially took responsibility for the maintenance of CiviCRM 4.6 LTS.
Why have a Long Term Support release?
CiviCRM is open source software with a vibrant and active community of developers and contributors. New functionality and features are being added on a daily basis and a new iterative version of CiviCRM is released approximately once per month.
The nature of open source software projects, and CiviCRM in particular, is to accept code developed from a wide variety of contributors, to satisfy a wide variety of use cases. With each release, the Core Team and contributing partners add new features at the request of organizations. In addition the CiviCRM Core Team and supporting partners diligently work on improving the underlying architecture of CiviCRM, upgrading software libraries and dependencies that CiviCRM relies on to function.
In doing so, it can sometimes be the case that changes happen in code that affect how the software operates, or causes customizations to break and need refactoring and maintenance to continue working as before. This is standard across any open source project, but it incurs a cost to all organizations that use the software because they must maintain internal expertise, or hire external expertise to analyze, upgrade, and adjust to any changes in newer versions. This is doubly so for larger organizations with heavily enhanced or customized installations.
As an open source project matures and evolves the software generally becomes more complicated, and as complication is added, the ability of any group of people to maintain existing functionality becomes more difficult. The CiviCRM Core Team mitigates this fact with the continual maintenance and update of test suites, and by maintaining quality standards for contributors to abide by. Despite this vigilance, it is inevitable that unintended consequences for some use cases occur, and bugs and regressions are sometimes introduced into new releases.
Even if all code is perfect, and does not cause bugs or regressions, changes to the software may necessitate changes to the processes of employees and volunteers of an organization. This may require additional training and documentation for staff, adding to the cost of doing business with the software.
The Purpose of the LTS
The purpose of the CiviCRM LTS releases are to provide organizations a version of CiviCRM with a focus on stability, security, and similarity. This means that generally only bug fixes and security fixes are incorporated into iterative releases of the LTS.
With this approach, the organizations that have their needs met by the LTS version can depend on it to continue to operate as it has been, for the life of the LTS, with a minimum of maintenance cost and risk. If there is no need for new features or functionality, then there is no need to introduce new, untested code or refactored underlying architecture and the risk involved with additional complexity entering the overall system.
The LTS provides a foundation for many organizations to focus resources on accomplishing their mission with a stable LTS system while limiting the cost of maintaining the infrastructure and business processes. Organizations are also assured that if security issues arise, such needs will be addressed and the data will continue to be protected.
LTS releases have been installed and used on production sites for a longer time frame than new short term support releases. They have been heavily tested and used for a wide range of use cases. Major bugs have been found and addressed long ago.
Skvare is proud to continue our contributions to one of the most stable and secure versions of CiviCRM in its long history. Version 4.6 was released on April 3, 2015, and continues to be used by thousands of organizations for over the past 3 years.
LTS going forward
Skvare remains committed to contributing and providing well maintained, secure, and stable versions of CiviCRM to our clients and the broader CiviCRM community. We continue our pledge to maintain the 4.6 LTS through the end of 2018. With the release of a new major version number of CiviCRM, version 5.0.0, Skvare is in communication with the Core Team and other partners to coordinate and establish the next LTS version. If the stability and security of the CiviCRM LTS is important to you or your organization, contact Skvare now to get involved, to access our expertise, or to discuss LTS version support into 2019 and beyond.
Comments
A couple of responses. Firstly & trivially - someone reading this might think that 5.0.0 is a major release - in fact it is the monthly release re-numbered. It is a bug-fix-heavy monthly release since bugs were a focus for that release - but still just a monthly release.
Secondly, regarding my own personal involvement in the LTS - the reason I originally adopted installing a fork of CiviCRM rather than the latest version was not because new fixes and changes were being introduced into CiviCRM but because bug fixes were not being released fast enough. For example we had a development cycle where a bug might be introduced when 4.6 was released but the fix for it was merged into 'master' which meant 4.7 - which itself was potentially not even released. We had a Fuzion fork - which was about ensuring that the fixes were being made available quickly, not about avoiding changes that were being introduced. We adopted an every second major release upgrade pattern for the same reason - ie. we were adding hooks to 'master' and to our fork to support our extensions and so to upgrade from 4.6 to 4.7 we then had to create our own fork of 4.7 to incorporate our additional patches, which was a lot of work.
The 4.2, 4.4 and 4.6 LTS forks were all basically the Fuzion fork with a few of our patches that were unsettled removed. So the process of creating the 4.6 LTS fork was basically that we took a release branch that had been stagnant for many many months (as core team had released 4.7 and moved on) and then we upgraded it to be the Fuzion fork and started putting out releases.
The move from yearly big poorly-tested code drops to monthly continuous integration code drops meant I no longer could see any benefit for me or my customers in using the LTS but unfortunately I had committed to support the LTS until the end of 2016. I was finally able to officially wash my hands of the LTS at the end of 2016 (although unfortunately it has continued to suck up my time in various ways since then).
I finally got back onto 'stock' CiviCRM around 4.7.21 - because all the bug-fixes and developer enhancements I needed were upstreamed at that point. I hadn't run stock CiviCRM since the early 3.x series before that (we had been forking for that long). I now upgrade every 1-3 months, except during peak fundraising season where I respect a code freeze. I actually deploy the rc rather than the stable release as I only rarely hit regressions in the rc and when I do I'm glad to have identified them early.
About 9 months before I was able to wash my hands of the LTS a member of one of the organisations I was working for said to me that the LTS was undermining CiviCRM as a product. She pointed out that a lot of the organisations that worked with partners and had the resources to find and resolve regressions were sitting back on the LTS, letting the small unsupported organisations work as their testers (someone else less charitably called the LTS a rort). It was also pointed out that we have something of a prisoner's dilmena - ie. the product is best keep free of regressions by everyone upgrading frequently and testing the rcs but each individual organisation's best interests (at least short term) might be served by sitting back and letting others upgrade and hit and fix any issues.
Since that I have been very conscious of that prisoner's dilema aspect and have tried to ensure we provide a lot of support to organisations that upgrade frequently. One way in which we do this is that we put a lot of effort into fixing recent regressions as quickly as possible. Since 5.0 was released we have had 2 regressions - one resulted in a patch release going out within 24 hours and the other within 48. By contrast, if you upgrade today from 4.6 or an early 4.7 version to 5.x and identify something that has stopped working then the costs of fixing it are obviously part of a business decision you made and the product maintenance team will not take an interest in it.
We did attempt to get people to demonstrate their support for the LTS through financial contributions. Over the 6 or more years that I was involved in the LTS 2 organisations were prepared to put their hands in their pockets to demonstrate the value they got from the LTS. JMA Consulting gave $1000 and Korlon gave a few hundred. While I appreciated their contribution, that amount would only cover a small portion of the time I have been pulled into spending on LTS related issues after I stopped supporting it. My best guess is that our current LTS costs the core team in the region of $200 a month to continue to provide continuous integration for and releases and to resolve the various issues where supporting the 4.6 fork blocks various changes to better support 5.x in our continuous integration (over and above the community time that goes into it)
As Eileen indicated 5.0.0 is unlike previous CiviCRM releases that changed the major version number in not including significant new functionality and code. The major reason for the numbering change was to mark the end of support for some versions of PHP that have not been maintained for some time with official security patches: PHP 5.3 and PHP 5.4 are no longer supported (https://civicrm.org/blog/totten/end-of-zombies-php-53-and-54).
Well that may be, but what has been going on with 4.7/5.0 is that new functionality and code is introduced in every minor/patch version. So although its not a "major" big huge change to code, there is constantly new code/features etc.. monthly.
For clarity - anyone on 4.6 now is on a version that is supported for security fixes until the end of 2018. Anyone on 4.7 or 5.x is on a version that is supported indefinitely at this stage.
This blog should not be understood to be endorsing choosing 4.6 over 5.x - rather I believe it's an effort to stir up interest to raise funds funds for another LTS at some future point. (If there is another LTS it will be a different process to the previous ones which were all based off Fuzion forks of 'old versions')
The purpose of this blog is to inform people why an LTS version is important. It is equally important to have a non-LTS version, but I'll let somebody else write that blog :) So from that sense it does not endorse a choice over 5.x for 4.6. What it means is that it's good to have an LTS, for the reasons clearly stated in the blog. Some organizations will want to have the newest version, with the latest functionality, and some organizations will want a release whose focus is on stability and maintaining what already works, long into the future.