Release Halide 9.0 and Halide 10.0

[alexreinking]

With #5228 landing, we are now producing well formatted binary packages that include the new CMake build; the autoschedulers on all platforms, including Windows; and a year's worth of changes and improvements to Halide that would be wonderful to put in our users' hands at the touch of a download link, rather than an afternoon of compiling.

To this end, we will create release/9.x and release/10.x branches and create tags and GitHub releases.

Any objections? We're trying to do this ASAP (by Friday morning)

[abadams]

My only comment is that if things get difficult, I don't see much value in releasing a 9.0 as well as 10.0.

[alexreinking]

That's a good point. 10.0.0 is the priority for sure

[steven-johnson]

Suggestion: create only release/10.x for now. Once it's clear that that branch is stable, we'll clone it to create release/9.x and release/11.x. (Yes, LLVM11 isn't final yet, but that shouldn't stop us from creating the branch.)

Related q: does semver allow for a 'prerelease' indicator somwhere? (e.g., we are currently building things labeled halide 12.0.0 though they are clearly prerelease...)

[alexreinking]

Yes, the full format is MAJ.MIN.PAT[-prerelease][+build-meta], so we could write 12.0.0-alpha or 12.0.0+datestamp in our package file names, git tags, etc. Note that CMake only knows MAJ.MIN.PAT.TWEAK numeric versions, which are a prerelease-free subset of semver.

[steven-johnson]

Since our package file names contain the Halide commit hash, adding datestamp is not really helpful. I'd vote for just adding -alpha (or -prerelease or whatever the favored is) for 11 and 12.

(Related thought: I wonder if it would make sense to note the specific commits for both Halide and LLVM used for our packages somewhere inside the package, just as a reference for people who may want to repro a package at a later date. Is this something that other packages do?)

[alexreinking]

Halide 10.0.0 is out!