Explicitly whitelist branches for generating releases on feedstocks

The main idea is that users sometimes don’t realize they need to fork a feedstock and PR a change to avoid a release. If we document this, that problem will happen less frequently. However, it would still be easier for users to make a change if they didn’t have to fork.

The idea behind having multiple branches on the original feedstock is to allow for having multiple versions supported simultaneously (e.g. a version 2 and 3 of Python). That being said, it is more often in practice that a maintainer works on one version and generates fixes for it than it is for them to add multiple versions. To make their lives a little easier, we should consider cutting a few steps out of this common maintenance process.

The proposal here is a follows. Releases should only occur from branches that we explicitly specify as releases branches. Any branch not on that list does not generate a release. Possibly we may want it not to build at all (unless it is in a PR). In other words, release branches must explicitly be whitelisted. All other branches are automatically blacklisted. This change will allow users that wish not fork, but do maintenance within the repo here the option. It also will avoid unpleasant surprises that a release was generated from some partially completed work.

The process for whitelisting should still be simple. This could be a list in conda-forge.yml that specifies the branches. By default, this should only include master. Users could add more branches to this list, but may need to re-render with conda-smithy depending on the implementation detail (this could be a very problematic implementation detail as it could result in everything ceasing to deploy when merged). The net effect being it is still quite simple to add a new branch for release. Also, this still can be done in a PR and be enabled when merged.

Using this proposal, it requires an explicit intentional action to create a multi-release feedstock. However, the effort required is still minimal, but is a bit closer to proportional with how often this is used. Also, this avoids people accidentally releasing things with this workflow. Plus, it removes the requirement of forking from maintenance simplifying maintainers lives in the process.

Potential syntax:

# conda-forge.yml
...
deployment_branches:
  - master
  ...

Please share any thoughts and feedback on this.

[beckermr]

Adding some color to this discussion from today’s gitter chat.

1. we can patch all feedstock branches with this via an admin migration
2. we can change staged recipes to default this on for master
3. we need to fix the GIT_BRANCH variable in smithy to make sure we can properly notify users if this is set incorrectly (see here: https://github.com/conda-forge/cf-autotick-bot-test-package-feedstock/pull/198/files)
4. we should notify users if this is set incorrectly

[almarklein]

Repeating a comment from a related discussion: I imagine that many packages can be updated by only updating a version number (and perhaps an url or md5). Being able to do this via the Github web interface makes this very easy, but it looks like GH only allows to create a local branch in that case.

Edit: I suppose you can fork and then update on the fork instead, but these are extra steps, which I’ll likely forget next time I do an update 😉