Handling prereleases

[iamthebot]

Comment:

Since the conda solvers do not exclude prereleases by default, providing 7.0.0a releases means simply listing a dependency like ipykernel pulls in prerelease versions. This is not, typically, desired. In conda/conda#5021 it seems like no consensus was ever reached on honoring PEP440 (which penalizes prereleases in version ordering). In large part because conda-forge has several non-python packages that adopt a versioning scheme that could be affected (eg; openssl).

tl;dr can we consider a different versioning scheme for ipykernel prereleases that lowers their priority?

[bollwyvl]

I am so sorry you were among the 6.5k or so downloads of the bad releases: as part of #185, the 7.x-alpha branch shipped to main in error, as authored and self-merged by me on #191. I did not notice the issue (even using ipykernel some!) for several hours. If you have any findings from your brief experience as an (unplanned) alpha tester of the releases in question, please feel free to share them here, or upstream on https://github.com/ipython/ipykernel.

Meanwhile: the offending releases were moved to the broken label by conda-forge/admin-requests#1613 thanks to the quick help of the conda-forge core team, so should no longer be considered by the solvers (I have verified conda, micromamba, mamba, and pixi). The state, as of when that was merged:

As that also shows, the pre-releases will be available going forward from conda-forge/label/ipykernel_alpha (and then presumably _beta, _rc, etc.)

We will try to do better in the future, but are lucky to have the conda-forge ecosystem to be able to rapidly identify and resolve these issues, or go back in time and fix previous issues.