As we near the end of 2015 we also near the end of the 4.4 LTS. This has been the second LTS release and it has been supported by the LTS team for a little over a year - meaning 4.4 has been supported for over 2 years in total. However, as announced previously the intention is for 4.6 to be the next LTS and we are now announcing that formal LTS support for 4.4 will stop at the end of the Jan 2016.
Is that the end of the 4.4 LTS?
More or less. This signifies the end of our commitment to provide bug fixes and security patches for 4.4.If a security issue arises and we feel that it is easy and safe to backport it then we would still put out a release. The same goes for a bug fix. However, we no longer commit to doing so.
When does 4.6 become the LTS?
It already is. I was under the impression we had 'announced' 4.6 as the next LTS but a quick consultation with Uncle Google reveals this was less clear than I thought. However, it...
In recent blog posts, we've expanded the long-term support effort to 4.4, discussed the release window (first and third Wednesday of each month), and experimented with release-candidates (RCs) for some point-releases (4.4.6, 4.4.7). This renaissance in release policy prompted a discussion of whether to continue doing RCs for all future releases. The RC concept is still controversial, but we reached a consensus on a similar concept -- nightly builds -- which achieves the original goals (and then some others).
The original goals of the RC experiments were two-fold:
- "To allow system-implementers to...
There has been a security advisory for CiviCRM. We recommend you immediately upgrade to one of the following versions:
Read the security advisories for details:
To receive future CiviCRM security notices, subscribe to notifications.
In addition, CiviCRM 4.4.6 contains 30 fixes, making it the most stable...Read more
Good day, folks,
The CiviCRM Partners list recently discussed the topic of release-announcements and release-testing. We'd like to treat 4.4.6 as a bit of an experiment to address two specific ideas about release-management:
- To allow system-implementers to allocate time/resources to handle upgrades promptly, we should provide specific, advanced notification about upcoming releases.
- To allow testing of the new release against real databases and real use-cases, we should provide a real, installable tarball before the final release announcement.
For this experiment with 4.4.6, we're providing a "release candidate" one week before the official announcement (scheduled for Wed, Jul 2). The hope is that this week can provide lead-time (to arrange logistics of upgrades) and provide testing-time (for anyone who wants 4.4.6 to be stable).
4.4.6 includes only critical bug-fixes and has been internally tested. However, even...