With the release of conda 4.2.0, we started a new pre-release program called conda canary. The name, inspired by Chrome Canary, is a “canary in a coal mine” reference.
Every new conda release is posted to the canary channel before it goes live for general availability. Patch releases–for example 4.2.14 to 4.2.15–may only spend 24 hours in canary before they are pushed to the default channel. Patch releases contain only bug fixes and minor improvements; they do not contain new features or major code changes.
conda config --add channels conda-canary
conda update conda
With the release of conda 4.2.0, we started a new pre-release program called conda canary. The name, inspired by Chrome Canary, is a “canary in a coal mine” reference.
Every new conda release is posted to the canary channel before it goes live for general availability. Patch releases–for example 4.2.14 to 4.2.15–may only spend 24 hours in canary before they are pushed to the default channel. Patch releases contain only bug fixes and minor improvements; they do not contain new features or major code changes.
The beginning of a feature release series works a bit differently. A new feature release spends about four weeks in canary. The first “cuts” of a feature release series may never make it to general availability. Here’s an example. For our recent 4.3 feature release, we posted conda 4.3.0 to the conda-canary channel on Dec. 14, 2016. Over the following weeks we released 4.3.1, 4.3.2, 4.3.3, and 4.3.4 to the canary channel. On Jan. 13, 2017 (a Friday!), we released conda 4.3.4 in the default channel for general availability.
Conda is engineered with very few dependencies that we don’t have direct control over. (The one big exception is requests and all of its dependencies.) That means that our test coverage is a reasonable indicator of the number of new bugs we might see with each release. While our test coverage has roughly doubled over the last year and now surpasses 85%, we still have work to do. Purpose #1 of the canary program is to help us catch bugs before they affect the bulk of our users.
There’s a purpose #2. It’s why the canary program will persist even if (when!) our test coverage surpasses 99%. With conda’s popularity, it has naturally become a dependency for other software. It’s not feasible for the conda maintainers themselves to test, or even know of, every downstream dependency. That job is incumbent on downstream developers. At the same time, we want to provide the tools for downstream developers to be successful, and the canary program is a central element.
For both goals, the more opt-in we have for the program, the more successful it will be. We understand the ask; we understand our canary users endure a certain amount of pain. We genuinely appreciate the sacrifice, and there’s an upside… The conda issue tracker is a fire hose of reports with noise that isn’t relevant to conda’s core function. For example, issues are often related to individual packages and how they are built. With the conda maintainers being human and having finite bandwidth, users who build a reputation for helpful bug reports stand out from the noise. Acknowledgment of the bug–generally with the addition of the red bug label–will be quick, and ideally the bug fix won’t be far behind. Oh, and then there’s the upside of getting all the great new features before everybody else 🙂
conda config --add channels conda-canary
conda update conda
Use the canary, Luke.
