I’ve got a user that needs an older version of a package I’m maintining that’s been recently added to conda-forge. How can I do that?
I think I can put the recipe in a new branch, and then it will get built. – is that correct? Or should I “downdate” the recipe in main to teh old version, get it built, and then update it again? that seems a bit awkward…
The usual process is to create a new branch for the old version yes. There a few tricks to make it less painful.
Let’s say you have a package called phone with version 3.4 but you want 2.7. Version 3.4 is currently being built from main. I’d do the following things:
Sync our clone with feedstock: git checkout main && git pull upstream/main
New branch: git checkout -b 2.x
Prevent an accidental upload on the branch push. We don’t want our freshly pushed branch to create a new upload. We can avoid this with two methods:
Make the recipe fail on purpose. This might be an exit 1 very early in the build script, or a bad URL for the source (e.g. add gibberish to the domain name), or a unsatisfiable dependency.
Add upload_on_branch: main to conda-forge.yml and rerender locally with conda-smithy rerender.
Push the 2.x branch to upstream (i.e. conda-forge/*-feedstock, not your fork)
Create a new branch off 2.x: git checkout -b build-old-2.7. Add the necessary changes for your old version, undoing whatever you did on (3) (i.e. revert the intentional errors or make sure upload_on_branch: 2.x + rerender).
Push build-old-2.7 to origin. This time it is the fork, not upstream!
Open a PR targeting 2.x and proceed as usual with your code reviews.
I hope that’s useful!
PS: Steps 1-5 would be nice to have as a subcommand, I guess. Imagine @conda-forge-admin, please create branch 2.x.