areusch commented on issue #14260: URL: https://github.com/apache/tvm/issues/14260#issuecomment-1467008597
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. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
