We always detect missing build scripts for `4.13.0-0` because the
release[^1] doesn't have any mambaforge artifacts. Given that we've
already created the build files, we don't need to check the release
again.
[^1]: https://github.com/conda-forge/miniforge/releases/tag/4.13.0-0
The glob pattern we were using was too permissive and detecting
miniconda build scripts as miniforge build scripts when they shared the
same version. I have rewritten the pattern matching code to ensure we
only look at files starting with `miniforge` and `mambaforge`.
The code for determining which Python version is bundled with which
version of Anaconda has not been updated in a while. I have added 3.10
and 3.11, both of which were used in bundles this year.
I also updated the URL for the source of this data, the Anaconda release
notes, because it has moved.
Anaconda and miniconda have changed their version string format again,
so the parsing needs to be done differently. `add_miniconda.py` can now
parse all existing definition files properly.
This takes inspiration from the similar script for miniconda, but it
simplifies in a couple of ways:
1. Use the GitHub Releases API instead of scraping HTML.
2. Don't perform a diff, simply add the latest release.
Lots of intermediate miniconda releases have been skipped in the past,
and it doesn't seem particularly valuable to backfill those.
Ivan Pozdeev
Alex Hedges
Christian Clauss
Sean McGivern
Fluency
Alex Hedges
Chris Barnes