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](https://github.com/apache/tvm/commit/d689733d5ae3d4d16455488cbfd9092c6f065029) the checked-in version numbers to say `v0.XX.YY` (substituting `dev0` for `YY`). This is referred to [loosely](https://tvm.apache.org/docs/contribute/release_process.html#cut-a-release-candidate) 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. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm/issues/14260#issuecomment-1467008597 You are receiving this because you are subscribed to this thread. Message ID: <apache/tvm/issues/14260/1467008...@github.com>
