Release Policy and New Release Candidates

Pubblicato
2014-09-09 19:32
Written by

We’ve been having some discussions among the folks who triage security issues, who publish new releases, and who maintain backports. We'll update the policy beginning with the upcoming 4.4.7 release (and related 4.2.19 and 4.3.9 releases).

Release Policy: The release window

For the past year (at least), the policy has been that new security releases must drop on the first Wednesday of a given month, and that other releases can drop anytime (with an undocumented requirement to target Tue/Wed/Thu). This aimed to strike a balance among predictability, security, and flexibility.

The revised policy is to allow stable point-releases on the first or third Wednesday of the month. This is another attempt to balance predictability/security/flexibility, and has a few notable implications:

  • Overall, it’s more predictable and understandable because it removes the open-ended timeframe for non-security point-releases.
  • It improves turn-around for security issues. In the current policy, the worst-case turn-around between fixing and releasing is 1 month.  The revision reduces this to 2 or 3 weeks (depending on how the Wednesdays line up in a given month).
  • Strictly speaking, it reduces the flexibility for non-security stable releases (e.g. we can’t drop a new stable release every week). But in practice I don’t think we've used that flexibility, so it doesn’t feel like a loss.
  • It does not obligate the project to do additional point-releases — but when point-releases are needed, it changes the timeframe.
  • It does not apply to alphas, betas or new major releases (e.g. 4.5alpha1 through 4.5.0). From a dev perspective, it’s helpful to iterate quickly on alphas/betas; and from an implementer perspective, there’s less urgency in an alpha/beta.

Release Candidates for v4.2.19, v4.3.9, and v4.4.7

We'll begin applying the policy with the upcoming point-releases. As with the previous 4.4.6 release, the 4.4.7 cycle will include a 1-week release-candidate period. Thus:

  • On Tue (9/9), release v4.2.19rc1, v4.3.9rc1, and v4.4.7rc1
  • Between Tue (9/9), and Tue (9/16), accept feedback and work on fixes for new regressions.
  • On Wed (9/17), release the stable v4.2.19, v4.3.9, and v4.4.7.

The new releases includes only critical bug-fixes and have been internally tested. However, even with limited changes, there's a risk of unintended side-effects and regressions.  Based on the specific changes, there are a few "at-risk" areas where you may want to test:

  • Price sets involving memberships
  • Form fields in which one enters a new CMS username or selects a contact by email [esp. for sites which have non-trivial security customizations]
  • Data exports
  • Merging duplicate contacts

For more information about release candidates, see https://civicrm.org/rc

Special Thanks To...

Eileen McNaughton (Fuzion), Nicolas Ganivet (Cividesk), Peter Haight (Giant Rabbit), Chris Burgess (Fuzion), and Dave Jenkins (Circle Interactive)