Set Halide version to 11.0.0

[steven-johnson]

I just took the liberty of creating release/11.x as a clone of release/10.x (as of fa9d6e1). This just updates the version in this branch.

[abadams]

Why based on 10.x instead of master? (I think the significant difference is how long it takes until we get nested vectorization into a release)

[steven-johnson]

Why based on 10.x instead of master?

Ah, I misunderstood the offline discussion earlier. My assumption here was that since Halide10 and Halide11 will be (temporally) very very close in time, it makes sense to keep them in parity in terms of features and bugfixes. There's no reason we have to do it this way, of course, but if I was a downstream user, I'd be a little puzzled if they came out within a couple weeks of each other, but one had more features. (Unless of course the nested vectorization relies on LLVM 11+).

That said, not sure I have super-strong feelings about it. If consensus is to scrap this and re-create the branch from current master (with ~one extra feature) then that's fine with me.

(Note that LLVM 11rc3 was just released yesterday, and is expected to be the 'final' 11.0 version of LLVM.)

[abadams]

I don't want to needlessly delay getting nested vectorization out there, but I also don't want to backport new features as a general rule. I don't think there's any issue with having a release with only one extra feature. I also don't feel that strongly about it though.

[steven-johnson]

I don't want to needlessly delay getting nested vectorization out there, but I also don't want to backport new features as a general rule. I don't think there's any issue with having a release with only one extra feature. I also don't feel that strongly about it though.

[steven-johnson]

Yeah, let's abandon this and redo from master soon -- e.g., #5283 should also end up in H11 (since we support wasm in llvm11).