Ensure release process points to project specific channel label(s)

[jaimergp]

Checklist

• [X] I added a descriptive title
• [X] I searched open requests and couldn't find a duplicate

What is the idea?

The current release process suggests uploading RCs builds to a conda-canary/label/YY.MM.x branch. This might end up becoming an unintentional clash for some packages with the same version scheme.

We can actually use several labels for the same package, so I envision something like the following for a hypothetic project 23.6.x RC series:

• rc (or even main?): general label for release candidates (e.g. CI users could have this job for general canary releases)
• 2023.06: for builds released that month (useful for tandem releases like conda+conda-build)
• project_23.6.x: exclusive for the project being packaged

Why is this needed?

Granularity and better control of what ends up where.

What should happen?

No response

Additional Context

No response

[jezdez]

2023.06: for builds released that month (useful for tandem releases like conda+conda-build)

Let's use 2023-06 to stay closer to ISO dates and prevent confusion with the version number scheme.

[jezdez]

project_23.6.x: exclusive for the project being packaged

Equally, but for more generic readability reasons, let's use project-23.6.x

[kenodegard]

We have learned that anaconda.org restricts labels to the following regex:

[a-zA-Z][0-9a-zA-Z_\\-\\./:\\s]*

[kenodegard]

Since labels are restricted to the above regex and the canary-release action is written with the expectation of only receiving a single label I propose we combine these into one (rc-project-23.6.x) and revisiting this at a later time?

[jezdez]

Since labels are restricted to the above regex and the canary-release action is written with the expectation of only receiving a single label I propose we combine these into one (rc-project-23.6.x) and revisiting this at a later time?

I think this was resolved, closing.