Conda Org Package Release Process

@jezdez is already working on this.

Since Jun 5, 2026.

### 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 https://github.com/conda/infra/issues/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](https://github.com/conda-incubator/ceps/blob/main/cep-8.md), 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`](https://anaconda.org/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`](https://anaconda.org/conda-canary): dev (e.g., untagged versions), alpha, beta, and release candidates
2. [`conda`](https://anaconda.org/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.