don't issue PRs with a in versions

[CJ-Wright]

It seems popular to put a in versions which are in alpha. We should remove those from our versions list.

[CJ-Wright]

xref: conda-forge/holoviews-feedstock#25 (comment)

[jakirkham]

Have mixed feelings about this.

On the one hand it would be really convenient to have automated dev releases too. Was actually very excited about this holoviews dev release.

That said, it might be too much strain to automate all dev releases in addition to formal ones.

Not to mention there is some extra legwork (e.g. these need to go into a different branch uploading to a different label). It's unclear to me (though it may be clearer to you) how we teach the bot to go through this dev release process. Plus some of it will still need to be done by maintainers unless we integrate the bot into conda-forge a bit more.

[CJ-Wright]

I don't know what is involved with releasing dev/alpha code to conda-forge.
I also don't know how many libraries put out formal dev/alpha releases.

I don't think that PRing into a different branch is an issue, I don't know how to do a different label.

I think it would be good to have/do a couple things to set this up:

1. Allow recipes to opt into a dev release system with a key in extra
2. In the opt in process they tell us if they want the bot to PR or directly push to the branch. Direct pushing could be useful for libraries that update frequently and don't want the maintainers to drown under PRs (although the CI strain may be great for this, and PRs don't have to be merged/paid attention to)
3. Build out auto-dependency tracking, since if we push directly to a branch we need to know that the deps are good.
4. If we go with a direct push model, we will need to do something so that the bot (potentially from a second account which is CF affiliated) can push to the branch, we should also take steps to make sure it can't push to the stable branch.

[jakirkham]

Typically creating a new branch and configuring it like so ( conda-forge/holoviews-feedstock#26 ).

Yeah, that's a great question and I'm not sure either. Suffice it to say it would increase the number of releases we would make.

Sure opting in is a good idea. Maybe we should just check for a dev branch. Of course standardizing what that means would help the bot and other maintainers. We can of course automate this process internally too once we have a spec.

Interesting idea regardless. Let's disentangle direct pushing from dev releases. There's already reasons to consider that independently of dev releases.

Yes, updating and track dependency constraints is very important. Which issue do we want to use as the focus of this discussion?

[CJ-Wright]

We can keep the dep tracking conversation here: #22

Sure, although I'd rather not have to look at the repo if possible.

Would it be possible to get docs for setting up rc/dev releases?

[CJ-Wright]

xref for direct push: #87

[CJ-Wright]

Attn: @ocefpaf

[CJ-Wright]

From @jakirkham in #110
Perhaps instead of continuing to blacklist these across the board we should devise an option for users to add an option to the meta.yaml to determine whether dev releases should happen and which ones. If the bot is able to inspect multiple branches, it would then know which branch to PR for free.

(As a side note, it might be nice for users to provide some sort of match at this point so that anything that matches is considered a valid release of a certain type (dev, main, etc.) and is sent to the correct place.)

[bsipocz]

It would be rather great for us to be able to opt in to build the dev versions and send them to main.

The package in question is a bit unusual given it relies on multiple remote data services and their constantly changing API, so top of master is always better and more stable than any previously labeled and released version. So we could really drop the dev from the version number anyway, but we currently keep it there to distinguish between automated releases and the more curated ones where e.g changelog and docs is cleaned out, etc.

[CJ-Wright]

We might consider this again as we have some more CI resources and better control of labels. @mariusvniekerk

[mariusvniekerk]

I'd recommend making a small design write-up of how this would work before accepting a change like this.

This would help serve as a starting point for how users could potentially opt-in. We may also want to perform some kind of rate limit for packages that just make a dev/alpha release to PyPI on every commit.