From 501cffb0a39fb4745866c697f3dca04498b3fd15 Mon Sep 17 00:00:00 2001 From: "Oriol (ProDesk)" Date: Tue, 4 Jun 2024 21:01:05 +0200 Subject: [PATCH] extend conda forge related docs --- doc/source/contributing/how_to_release.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/doc/source/contributing/how_to_release.md b/doc/source/contributing/how_to_release.md index 95d23f7f3b..a64c023312 100644 --- a/doc/source/contributing/how_to_release.md +++ b/doc/source/contributing/how_to_release.md @@ -46,3 +46,22 @@ ArviZ uses the following process to cut a new release of the library. ``` 9. If the versions were updated in step 3, update also the [conda forge recipe](https://github.com/conda-forge/arviz-feedstock). + + :::{important} + There is a bot that opens a PR automatically to update the conda forge recipe. + However, **all dependencies must be checked manually** to ensure the ones in + the recipe match those in the requirements + ::: + +10. (here for reference but we really want to avoid it) If for some reason there were an issue + with a release, there are two tools to fix it in conda forge: + + * repodata patch: If there is a new release for one of the dependencies with breaking changes + for example, a repodata patch should be submitted to conda forge to prevent users + from installing a broken environment. + * mark a build as broken: If the dependencies were incorrect in the recipe, then the existing + build should be marked as broken and a PR (completely manual) should be submitted + to the arviz-feedstock to fix the recipe. Note that if this is being done for a release + different than the latest, changes should not be merged into `main` but on a dedicated + branch, the conda-forge package build is generated all the same but the history is kept + tidier and prevents issues when a new release is published.