Published
Tuesday, June 24, 2014 - 16:15
Written by

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:

  1. To allow system-implementers to allocate time/resources to handle upgrades promptly, we should provide specific, advanced notification about upcoming releases.
  2. 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 with limited changes, there's a risk of unintended side-effects and regressions.  Based on the specific changes in 4.4.6, there are a few "at-risk" areas where you may want to test:

  • Screens which use profile forms
  • Contributions made "On Behalf Of" another
  • Upload and display of contact images
  • Concurrent delivery of scheduled CiviMail blasts

For downloads and other details, please see:

https://civicrm.org/rc
 

Filed under

Comments

Sounds like a good initiative, Tim - happy to see CiviCRM's processes maturing!

What is the recommended action for sites to take if they find the release doesn't upgrade cleanly, in order to signal that the release candidate may not be ready for final release?

I see civicrm.org/rc gives this advice to sites testing out the RC -

  • Please report (issues) ASAP. We will attempt to fix and publish additional RCs ASAP. (Should this direct people specifically to JIRA or forum?)
  • Issues identified after Mon, Jun 30, may be too late to help 4.4.6 (but may help 4.4.7 or 4.5.0).

Any of the following would be a fine way to report a problem: comment on this blog, ping me on IRC, assign an issue to me in JIRA, or post to the 4.4 upgrade-testing forum.

If one does find a problem in upgrading to 4.4.6rc1, and if one is upgrading through multiple versions (e.g. 4.4.1 => 4.4.6rc1), it would be a good diagnostic technique to try a lesser upgrade (e.g. 4.4.1 => 4.4.5) to see if the same problem arises. That's not a hard-rule -- but it should help triage the issue.

THANK YOU!  THANK YOU!  THANK YOU!  This will make it much easier to schedule time for that type of testing on Pantheon in advance of the release.  

I know that beta upgrades are generally not supported, but if the idea is to run this on a production stack, can we count on RC upgrade support?

Short answer: Not with 4.4.6.

Long answers:

1) The RC should ideally be installed on a test/staging instance which uses the same software-stack/configuration as the production instance.

2) There are very real possibilities that providing upgrade-support for RCs would either (a) cost nothing or (b) require extra patches (which will in turn increase complexity, require more testing, and prolong the release-cycle). We have to assume the worst-case (b). Sacrificing upgrade-support for 4.4.6 allows us to converge on the final release more efficiently -- which makes the release process more affordable and timely.

3) The importance of upgrade-support depends a lot on the circumstance of the person testing -- if one has a structured deployment process with separate instances for testing+production, then one can install an RC on the test-instance. If the RC has a problem, you just reset the test-instance. (And frankly... regardless of the release-policies for Civi, Drupal, or any other supplier, it's in one's own best interest to have a test-instance which can be quickly reset.) But for folks who don't or can't have dev/test-instances, upgrade-support is critical, and it's not a good idea to use an RC.