At the beginning of this year I announced the intention of the LTS team to support 4.6 as the next LTS and we are committed to keeping 4.6 secure until one year after we stopped supporting 4.4 - ie. the end of January 2017. As with 4.4 the level of support will tail off as key contributors move off 4.6. At this stage we are still getting a large number of fixes for 4.6 and expect to see monthly point releases continuing for the rest of the year.
However, 4.6 might be the last LTS as we know it. Before you get that worried look on your face ... this is a good thing.
The LTS came out of a desire to keep providing fixes and security patches to stable sites without introducing poorly tested or large scale changes that might have an impact on core functionality or custom code or extensions. Prior to 4.7 the core release cycle was always focused on major version releases with even minor bug fixes often being delayed to the next major version, a version that might include massive change and introduce further bugs. This was a huge disincentive to fix bugs in core and to fix core to better support extensions. The LTS provided us with a way to encourage and distribute these fixes while also requiring people got them into the next major release.
In 4.7 the core team have adopted a much more LTS-like approach - but better. At CiviCon last week Tim & Coleman presented the 2 prongs to this
1) Leap by extension - essentially the idea that we will be moving towards major changes being grand-fathered in as opt-in extensions (until such time as the existing one can be deprecated). A key area where this is being proposed is in replacing core forms screens with more responsive theming, a more modern look and a flexible usability focused approach. There is exciting work going on in this area ... but of course more money will help if you want to push this forwards.
2) Iterate by month - this is the idea of a predictable release schedule which looks something like this
- First week of the month - list of patches that have been submitted to core (PRs) is groomed by a release manager and the community is invited to take part in the QA process.
- Second week of the month - community members indicate their willingness to take part in the process are are matched into teams with other community members and core team members
- Third week of the month - QA is done on the proposed patches by those taking part and as appropriate they are merged.month
- Fourth week of the month A release candidate tarball is made available and the community is invited to test it both on the demo site and by downloading it onto staging sites.
The tarball is then released on the first Wednesday of the month.
Non technical people can take part in this process as by testing the code although we will always need the devs to do the code review. I'm hoping that one of my fellow sprinters from the Denver sprint will be posted a blog fairly soon about that side of things.
One of the implications of this process is that 4.7 implicitly has long term support. There is no intention to release another major version in the medium term future. CiviCRM is moving to a more modern continuous integration approach and the LTS team believes the best thing we can do to ensure there is a secure reliable version of CiviCRM is to put our efforts into the processes outline above, which the core team is spearheading.
FAQ
What if the core team DOES decide to release a new major release?
We don't see a new major release on the horizon at this stage but if it happens the LTS team is committed to ensuring 4.7 has support until at least the end of next year. There is a chance the core team may 'rebrand' 4.7 to 5.0 to recognise the change of process - but if this happens will treat that as a continuation of 4.7. A new major release would be a release with a step change in code and compatibility.
What version should I upgrade to if upgrading now?
4.7
What about extensions & custom code? Will they break on point releases?
It depends how they have been written. We now have an extensions working group, and are looking to kick off this conversation.
What is the release timeframe for this month?
Release timetables are here https://github.com/civicrm/release-management - we are running behind this month due to the sprint and expect a reduced review cycle starting next week.
Comments
Thanks for detailing the new release process, Eileen. This approach presents some great opportunities for the project.
Hi Eileen.
I understand how this release policy is making your lives a lot easier, and I know it must have been quite challenging in the recent months. Thanks for all the great work!
However, my concern from a user organisation's point of view is the following: Doesn't that mean that if there is a new critical security fix you cannot roll it out unless you do a (very expensive) full regression test. Why? Well, you won't just get the security fix, but also -inevitably- a host of other changes, that potentially break your workflows. This will affect big user organisations much more than small ones, and I'm not convinced we should make their life harder than it already is.
Ideally we would maintain an additional stable branch that would only issue security fixes, but I do realise that this basically means keeping something like a LTS after all.
I'm assuming we can discuss that on 6/30 with Tim and Coleman in their webinar, right?
Bjoern I guess the point is to be a lot more careful about what fixes make it in & put them in an extension if they might be breaky / cause significant change.
Unfortunately the most breaky fixes tend to be the security fixes :-(
Hi Eileen.
Tim and Coleman made a very good case for the "Leap by Extension..." concept yesterday. I still think that this might have a negative impact on CiviCRM security on the user end, but I guess we'll just have to give it a try and see where the approach causes problems.