As our North American colleagues (and those who have made the big trip over there) head into the governance sprint now seems like a good time to recap on product maintenance in CiviCRM. Product maintenance, as I discuss, is the monthly routine processes we do to incorporate patches & contributions into the CiviCRM product. This blog is kinda long & weedsy - so if it’s not for you then take a look at this baby octopus instead.
Over the past year I have been volunteering time to help out in the effort to raise funds for the Hundertwasser Art Centre. In order to help the HAC project I have added a couple of reports that may be useful for other pledge users (or possibly sites that track money received through campaigns).
All sites are strongly encouraged to upgrade to the latest secure versions of CiviCRM: v4.7.14 and v4.6.24.
For many years CiviCRM has had the capability to log all actions that take place in the database but while it mostly works well there have been a few issues. I looked into these recently and came up with some improvements, which shipped in 4.7.7 - but if you want to take advantage of them there are some actions you might need to take. This article is mostly intended for a technical audience.
How does CiviCRM logging work?
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.
We have replaced the 4.6.17 release with a 4.6.18 release. This addresses some 4.6.17 regressions that notably affect CiviVolunteer and the estimating groups count on the mailing screen. There was also a pdf creation related error. The issues are to do with 4.6.17 security backports from 4.7 that missed something out.
If you have not yet gotten the security fixes in 4.6.17 you should choose 4.6.18.
Inspired by a colleague I suggested we report today's sprint events in Haiku. Here are the burnt offerings from Colarado!
Bugs & QA team
Many Civi Bugs
Ate the sprinters pesticide
And died horribly
Busy sites have often encountered problems with deadlocks on the group contact cache. There were no less that 3 different code contributions to mitigate this problem put up for 4.7.8 and a number of other discussions have been going on in JIRA.
Merged into 4.7.8 are some improvements which we hope will mitigate this problem for those sites that experience it. JIRA is the primary source of information on this, however I wanted to share a brief overview.