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).
Pre-release goals
The original goals of the RC experiments were two-fold:
- "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."
Goal 1 has been mostly addressed by revising and reaffirming the release-window policy (first and third Wednesday) to cover all point-releases. Goal 2 is addressed on an on-going basis with nightly-builds.
What are nightly builds?
A nightly build is an automatic, unsupported build of the CiviCRM source-code -- once each day, an automated script on civicrm.org examines the latest code in CiviCRM's git repositories. For each "tag" or "branch", it prepares installable files (tarballs, zip files) and publishes them on http://dist.civicrm.org . These files may be used for testing purposes.
When should I use a nightly build?
- You should only use a nightly build if you have separate installations for testing ("staging", "dev", "demo") and production ("live"). Nightly builds are not intended for use on production sites.
- If you reported a bug which has been tentatively fixed, you can test the bug-fix by downloading/installing the nightly build.
- If you install updates on behalf of clients, you can use nightly builds to test new releases before they come out.
- If you're participating in development of a new feature (e.g. testing, documentation, coding), you can use nightly builds to try it out before release.
Why shouldn't I use nightly builds in production?
For production sites, it is important to apply the correct database-upgrade. A bad or inconsistent database-upgrade can cause confusion (at best) and data-loss (at worst). Unfortunately, the database-upgrade is subject to change from day-to-day (until the final day of release). To summarize a few possible paths which are OK or dangerous, let's pick a few examples (e.g. using "4.5.0" as a representative stable release, "4.5.3-20141103" as a representative nightly, and "4.5.3" as another stable release):
- OK: Upgrade a production system from 4.5.0 (stable) to 4.5.3 (stable)
- OK: Upgrade a test system from 4.5.0 (stable) to 4.5.3 (stable)
- OK: Upgrade a disposable test system from 4.5.0 (stable) to 4.5.3-20141103 (nightly)
- OK: Install a new, disposable test system from 4.5.3-20141103 (nightly)
- Dangerous: Upgrade from 4.5.3-20141103 (nightly) to 4.5.3 (stable)
- Dangerous: Upgrade from 4.5.3-20141103 (nightly) to 4.5.3-2041104 (nightly)
Freeze Periods and Point Releases
An unofficial goal of the RC experiments was to introduce a "freeze" period for point-releases in which the tentative RC could be tested while setting a very high-bar for accepting any further changes. This turned out to be the most controversial aspect of RCs -- and understandably so. During a freeze, new bugfixes may be written but withheld. A freeze involves many debatable decisions, such as (a) how long the freeze should last, (b) how to technically implement the freeze, and (c) which changes are important enough to get in despite a freeze. These factors may be swayed by subjective details (e.g. the release-dates set for the previous and next releases; the overall magnitude of changes in the release; etc).
Consequently, there's no official policy on freeze-periods for point-releases. Unofficially, release-managers may enforce a soft-freeze on particular releases. For example, Eileen (wearing the 4.4 LTS RM hat) plans to implement a soft-freeze for one week before each 4.4.x release. During a soft-freeze, the release-manager holds off on accepting PRs until after the point-release is finalized.
Other benefits
- The nightly builds are automated and always available -- there's no requirement for a release-manager to take the initiative and prepare/publish them.
- The nightly builds work with any branch or tag -- including master. You can try out the latest code for the next major release at any time -- even if you don't know how to use git or civicrm-buildkit.
