[CI] fix broken handling of release candidates in anaconda_prune.py

[PhilippvK]

Had to port #146 to Conda as well to fix CI.

HOWEVER I found the actual cause of that RC-related issues:

The rc tag for the latest TVM should be v0.10.rc0 Instead of v0.10.0rc0. Renaming that tag leads to the expected behavior for nightly builds based on the v0.10.dev0 instead of v0.10.0rc0.

@tqchen Should we really add a workaround to deal with that mistake/inconsistency or just recreate the tag in the upstream repo with the proper name?

[tqchen]

in this case i think we should rename/delete the tag (rc tag should be removed after release).

cc @driazati

[driazati]

Based on https://github.com/apache/tvm-rfcs/blob/main/rfcs/0067-quarterly-releases.md the version numbers should be v<major>.<minor>.<patch> (though we've not done any patch releases), I think we should add a workaround here instead of renaming the tag so we can keep the numbers consistent going forward

[PhilippvK]

@driazati the problem is, that a workaround would need a patch in tvm/version.py to ignore any rc tags in the git describe --tags --match … subprocess call. So we can not fix it here downstream.

According to https://tvm.apache.org/docs/contribute/release_process.html the following scheme should be used for RC tags: major.minor.patch.rc[0-9]

Therefore v0.10.0rc0 is definitely a typo leading to these issues. The correct tag v0.10.0.rc0 wouldn’t have resulted in these nightly packages being uploaded to GH, PyPI and Conda with a wrong name, thus we wouldn’t need to deal with them in the respective cleanup scripts.

Please let me know if I should really patch version.py upstream as well as the broken cleanup scripts in this repo to deal with rc used as a suffix instead of the expected .rc.

[driazati]

It might be worthwhile to patch version.py to check for incorrect version tags (something like any tag starting with v<num> should match one of v<num>.<num>.<num> or v<num>.<num>.<num>.rc<num> to ensure that typos like that are caught in CI

[tqchen]

Agree some form of scanning checks can be useful. The problem is that the version tag themselves are not part of the code change, as a result harder to be caught by the CI. having a separate script which periodically checks the tags could make sense.

Regardless, perhaps we should go ahead and delete v0.10.0rc0 to make sure the nightly recovers, see if we all agree here.

[tqchen]

Merging this to be consistent with #146. the mainline's rc tag is also deleted

[PhilippvK]

@tqchen Thank you for merging and cleaning up the rc tag.

Sorry for not coming up with a followup in-time. I hope I will find some time in the future for adding a nightly check for valid version tag names.