Conda Org Package Release Process

[kenodegard]

Summary

Currently, packaging any conda org project is a per-project process. There are some loose standards but no official standard.

The release process followed today (see #541) usually ends with a handoff from conda release managers to the Anaconda Inc. packaging team (and/or to conda-forge) to be packaged and made generally available. This handoff doesn't make sense for several reasons:

1. As a community, we are beholden to the bi-monthly release schedule defined in CEP 8, whereas the Anaconda Inc. packaging team is beholden to other goals and timelines (e.g., security reviews, LTS, etc.).
2. Since conda is a community project, it's not unreasonable to expect a future where the release manager is a community member (and not an Anaconda Inc. employee), so having a step in our release process depending on Anaconda Inc. is illogical.

To circumvent this, we propose reviving the conda channel. By adding this channel back to our release process we can understand the different channels as having the following purposes:

1. conda-canary: dev (e.g., untagged versions), alpha, beta, and release candidates
2. conda: tagged releases, these are the supported conda versions, once a version of a package lands here the release process for said version will be considered complete
3. defaults/main/conda-forge: "stable"/"reviewed" releases

It will be the responsibility of the conda release managers to make canary builds available on conda-canary and to make tagged builds available on conda. They may choose to aid packaging teams with their build process but delivering conda, conda-build, etc. to these other channels will not be required for a release to be considered complete.