The first Wednesday of the month is an important day for the CiviCRM community. It’s the day where a new, scheduled monthly release drops. These normally include bug fixes, minor features changes and improvements. Nothing earth shattering (hopefully). Upgrades are typically routine and easy. For many, this is a fairly painless process to manage, especially as the ease of upgrade and release reliability have improved over the years.
For others, the pace of upgrades may be too fast. Or perhaps they have customizations that might break, and the stress of upgrading keeps them up at night. Whatever the reason, it’s always possible to maintain an older version of CiviCRM. But that also requires technical skill and time. As a solution, the community supported an LTS version (long term support) for many years. The last LTS is 4.6 and, well, it’s slowly going away. So, now what do we do for organizations that don’t want to upgrade every month?
Enter Extended Security Release
Starting with version 5.7 (released on Nov 7th), the CiviCRM Core Team will maintain an additional version of it called Extended Security Release (ESR) that will not advance along with the monthly release cycle, but will instead receive only security patches and critical bug fixes. This means that for those that don’t want to upgrade monthly and that prefer consistency over new features, ESR presents an option for them. For those that want to continue with latest version, the regularly scheduled monthly release works same as always (5.8 will be released on December 5th, mark your calendars!).
Wait, what? 2 versions of CiviCRM?
Think of CiviCRM ESR as a snapshot of CiviCRM 5.7 that periodically (as needed) receives critical updates, but no new features. Subsequent monthly releases still happen… 5.8, followed by 5.9, and so forth. CiviCRM ESR exists as an older version that offers more consistency over time, but fewer new features. It in no way replaces the latest stable version released monthly.
We anticipate some questions, so here are a few common ones we’ll address right away:
-
Do I have to use ESR? Nope. If you’re comfortable with the monthly updates, or if you’re just starting out with CiviCRM, use the latest monthly release.
-
How long is ESR supported for? 5.7 is guaranteed to be supported for 6 months. We hope that we can support it for 12 months.
-
Is ESR free? CiviCRM ESR requires a monthly subscription for organizations to use (subscribe here). It is free for CiviCRM members (become a member here).
-
What happens if we don't raise the funds needed to support ESR? It goes away. That simple.
-
Does it include additional support? No. Support for CiviCRM is the same whether using ESR or or the latest stable monthly release. It’s freely provided by the community or available via a network of expert partners.
-
Is there more information available? Yes. Visit https://civicrm.org/esr for more details. We’re continuing to update this information as well.
Let’s wrap this up…
CiviCRM Extended Security Release is officially starting with version 5.7 and will include only security updates and critical bug fixes for 6 months, guaranteed, or longer if we can raise enough support for it. The normal monthly releases continue on.
Comments
Thanks Josh - it will be interesting to see if organisations subscribe for this service or not. Worth trying
I would note that most organizations don't upgrade every month but they do need to upgrade to the latest when we issue security releases - so people who pay for the ESR will be getting those security fixes applied to 5.7 rather than needing to upgrade to 5.9 or whatever to get them
Thanks Josh, How does this differ from the LTS? And the support period is really short? Most clients who work with CiviCRM dont upgrade for at least 3 years but some even longer, so it doesn't solve their problems with security.
I think this question really shows a bit of a divide in assumptions about CiviCRM code.
For many developers, web hosts and probably most clients, a CiviCRM installation is something to launch and then only minimally maintain when necessary, and every maintainance call is expensive and potentially fraught with risk for both client and whoever they've hired to do the maintenance. And then every several years, make the investment of updating it all and relaunching on the latest version. From that perspective, the longer the ability to not touch the server and code, the better.
For larger installations that use CiviCRM a lot, and for CiviCRM core coders, maintaining old versions feels like the wrong thing to do - the better thing to do is to assume you'll keep your CiviCRM + infrastructure + other bits all relatively up to date. Not necessarily the latest, but recent enough so that if a security patch comes along, you're not stuck with manually trying to fix things.
I can see reasonable arguments for both these approaches and sometimes I think the right answer depends on the client and the code, but in general, I'd say that the first approach should be avoided more and more, and that in the web world in general, it's now generally the wrong approach.
If you disagree, then you might want to reconsider the potential benefits of going with the "keep up", and also reconsider how you can reduce the costs. As a simple example - the speed and memory requirement benefits of php 7 over php 5 have been remarkable, but wouldn't be accessible if you're still on CiviCRM 4.6.
One of the key things that has changed the equation in the past years (for many projects, but certainly for CiviCRM) is the fairly wide coverage of automated tests - it means that we can focus our human time and attention on just our site-specific oddities that might not be covered and are critical to the site.
Think of ESR as a "Mid Term Support" version. 4.6 LTS was supported for years....The goal of ESR is to have a "middle way" between supporting a version for multiple years, and a new version every month. This decreases the upgrade cycle costs for sites with heavy modification and/or custom functionality. If you don't have a lot of customizations, then having the latest features is "cheap". Sites with heavy custom functionality prioritize stability over new features, especially in the short term. With security only releases, people managing complex sites can focus on just minor updates with no API or functionality changes that would necessitate reevaluation possibility re-development, and only go through a more complex process a few times a year...
Alan has summed it up pretty well. There will always be sites that make the business decision to upgrade less often. This business decision has benefits and costs. The ESR is one way of associating the cost of maintaining a second version on those who make a business decision to not upgrade to the latest version when a security release comes out. Another way is for them to pay consultants to backport patches for them