[VOTE] Release Apache TVM v0.11.1

[leandron]

Dear TVM community,

This is a call for vote to release Apache TVM version v0.11.1. #14259 for any edits you would like to see included in the release notes.

Link to release notes:
#14259

Link to release candidate:
https://dist.apache.org/repos/dist/dev/tvm/tvm-v0.11.1-rc1/

Link to github pre-release page:
https://github.com/apache/tvm/releases/tag/v0.11.1

Everyone is welcomed to vote. Please vote by replying to this thread explicitly.

+1 = approve
+0 = no opinion
-1 = disapprove (provide reason)

RC0

Vote will close Monday, Mar. 13th at 23:59PM GMT.
We found a problem in RC0 which was fixed by #14300
So an RC1 package was published and this post was updated.

RC1

Vote will close Thursday, Mar. 16th at 23:59PM GMT.
Start of the voting thread at #14260 (comment)

[areusch]

+1

[Hzfengsy]

+1

[masahi]

+1

[tqchen]

+1

[Johnson9009]

+1, by the way the version is still 0.11.0dev, this should be changed to 0.11.1 too.
Actually, I want 0.12.0 more, because the 0.11 branch is behind too much than main.

[driazati]

Checked building with this config minus ETHOSN and ETHOSU and it seems to import correctly and typing_extensions is installed during a pip install. As @Johnson9009 pointed out though the rc package will need to be rebuilt after doing https://tvm.apache.org/docs/contribute/release_process.html#update-tvm-version-on-main for v0.11.0 -> v0.11.1 everywhere

[areusch]

-1

yeah agreed we should fix the version numbering first before releasing, sorry i forgot to check that. -1 til we do that.

[leandron]

Just to clarify what is missing: is it updating (e.g. via version.py) the version numbers in the source package so that it reflects the right version when built?

@driazati I'm asking because this seems like a reasonable step, but it is not what is instructed at https://tvm.apache.org/docs/contribute/release_process.html#update-tvm-version-on-main. This one is for the next release, which I think it is correct in main?

[driazati]

The version numbers should reflect the current version (and it's in more places than version.py). There should be a PR against the v0.11.0 branch like #12190 that updates the version numbers from v0.11.0 to v0.11.1, then we tag that commit once it's merged as the new v0.11.1

[areusch]

okay i took a look here and i think something is messy with our process. here is the process now:

1. cut a release branch, then update the checked-in version strings by running python3 version.py, then creating a PR out of the diff. that typically should look like https://github.com/apache/tvm/pull/12190/files as @driazati mentioned. Notably, the checked-in version numbers should say v0.XX.dev0.
2. when it is time to call for a vote, create and sign a tar apache-tvm-v0.XX.Y.rc0.tar.gz whose files look AS IF they were the final v0.XX.YY release. That means they are in a directory apache-tvm-src-v0.XX.YY/ even though the created .tar is actually v0.XX.YY.rc0.
3. publish the tar to the dev apache server, then call the vote wait for it to conclude
4. presuming the vote is accepted, tag v0.11.0 at the same commit from which the tar was generated, then mv dev/svn/apache-tvm-src-v0.XX.YY.rc0.tar.gz release/svn/apache-tvm-src-v0.XX.YY.tar.gz. (NOTE: this move drops .rc0 suffix, promoting rc0 to the release without requiring the release manager to resign the tar).

however, here's where the process gets messy. Somewhere before step 2, there is also a step where on the release branch (v0.XX.YY), we update the checked-in version numbers to say v0.XX.YY (substituting dev0 for YY). This is referred to loosely in the release docs. At this point, the release branch v0.XX.YY is now "final" because the checked-in version matches the release version, even though this update is done before the vote takes place (when we are actually merely generating the rc0 tar). If a second rc1 is created, or if a second revision release v0.XX.1 is needed, the checked-in code is no longer dev0.

i think we have two possible solutions:

1. make the v0.XX.YY branch into a v0.XX branch, then when creating any .rcN .tar for voting, create v0.XX.YY tag commit which is the tip of the branch but with the checked-in versions set to v0.XX.YY.
2. whenever we need a .1 revision release, make a v0.XX.1 branch from the tip of the v0.XX.0 branch, and continue the practice of modifying the checked-in versions to v0.XX.1 right away.

personally i think 1 is cleaner in terms of git commit history and is easier to cut a revision candidate. however, 2 is less of a departure from our existing practice.

either way, still -1 on this one until the release tar has the right versions. the previous v0.10.0 and v0.9.0 release tars do have the correct version strings there.