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
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.
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?
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.