[Release] v0.13.0 release schedule

[ysh329]

Although last released v0.12.0 is on 17 May, the date of v0.12.0 branch cutting is 9 Apr. In other words, the v0.12.0 release is based on main branch of 9 Apr. It has been almost three months since April 9th.
According to our RFC-0067 about quarter-based releases, I hope to release v0.13.0 version in mid July. It's meaningful especially for AI infra companies which needs regularly merge with release version.
In order to continue with our agreed release cycle as per discussion in RFC#67 , I'd like to propose a schedule for our next TVM release: v0.13.0.

This schedule is tentative and may change as we progress through the process. In case dates change, this thread will be kept updated.

The proposed schedule is:

• 1 July 2023 - a branch v0.13.0 to be created from main
• 1 July 2023 - a tag v0.14.dev0 to be created, marking the beginning of the next development cycle
• 2 July 2023 - modifying the version recorded to v0.14.dev0 on main branch, Update version to 0.14.dev0 on main branch #15208
• 3 July 2023 - modifying the version recorded to v0.13.0 on v0.13.0 branch, [release] Bump version numbers to 0.13.0 #15216, [Release] Fix version number on branch v0.13.0 #15273
• 7 July 2023 - cherry-picking soft deadline
  • during this time any reasonable change can be merged, comment on this issue with the commit you would like added to the release branch
• 12 July 2023 - cherry-picking hard deadline
  • during this time only critical changes will be merged, comment on this issue with the commit you would like added to the release branch as well as the reasoning for adding it
• 13 July 2023 - Draft release notes published, [Release] v0.13.0 Release Candidate Notes #15295
• 14 July 2023 - prepare release candidate packaging v0.13.0.rc0 and uploading
  • Create tag v0.13.0.rc0 and Github release page: https://github.com/apache/tvm/releases/tag/v0.13.0.rc0
  • Upload to Apache repo: https://dist.apache.org/repos/dist/dev/tvm/tvm-v0.13.0-rc0/
• 14 July 2023 - release voting opens, [VOTE] Release Apache TVM v0.13.0.rc0 #15313
• 20 July 2023 - voting result, [RESULT] [VOTE] Release Apache TVM v0.13.0 #15376
• 20 July 2023 - upload the binaries to Apache mirrors and create a new release TAG named v0.13.0 meanwhile remove the pre-release candidate TAG v0.13.0.rc0
• 20 July 2023 - release date
• 22 July 2023 - Update the TVM Website

Call for release managers: in case you want to be involved in upcoming releases, please manifest your interest in this thread and we'll try to organise. 😆

See also:

• Release steps
• TVM release process docs.

cc @apache/tvm-committers @driazati @areusch @Mousius @tqchen @AndrewZhaoLuo

[tqchen]

Happy to help with some of the branch cutting works, Thanks @ysh329 for volunteering

[Hzfengsy]

Thanks @ysh329. Happy to help with things that need permissions!

[spectrometerHBH]

I volunteer to help manage the release

[Johnson9009]

Can below two steps be merged into one? Because these steps have some relationship, i.e., the commit of "v0.14.dev0" must be the next commit of branch v0.13.0, in addition these two steps can be done quickly as long as the contributor has enough permission.

1 July 2023 - a branch v0.13.0 to be created from main
3 July 2023 - a tag v0.14.dev0 to be created, marking the beginning of the next development cycle

In addition, there need add another step for modifying the version recorded in main branch code to "v0.14.dev0", because this step need to send a PR and need run all tests, so it maybe need 1~2 days to be merged.

[ysh329]

Can below two steps be merged into one? Because these steps have some relationship, i.e., the commit of "v0.14.dev0" must be the next commit of branch v0.13.0, in addition these two steps can be done quickly as long as the contributor has enough permission.

1 July 2023 - a branch v0.13.0 to be created from main
3 July 2023 - a tag v0.14.dev0 to be created, marking the beginning of the next development cycle

In addition, there need add another step for modifying the version recorded in main branch code to "v0.14.dev0", because this step need to send a PR and need run all tests, so it maybe need 1~2 days to be merged.

Good question. I checked recently commit history records about 0.xx.dev0 on main branch and found the next submission of tagged 0.xx.dev0 were not PR changed version, which were non-standard.

I think these two things about a branch v0.13.0 to be created from main and a tag v0.14.dev0 to be created can be merged. Of course, the next submission of tagged 0.xx.dev0 should be the PR modifying the version recorded like this.

I modified the schedule and add a step about modifying the version recorded in main branch code to "v0.14.dev0". Besides, I add an item about modifying the version recorded in branch v0.13.0 like this.

[ysh329]

Please help create branch named v0.13.0 from main and v0.14.dev0 tag. @tqchen @Hzfengsy

[spectrometerHBH]

Please help create branch named v0.13.0 from main and v0.14.dev0 tag. @tqchen @Hzfengsy

The new branch and tag is now ready.

[ysh329]

I commit a PR about modifying the version recorded to v0.14.dev0 on main branch: #15208.

Hi @spectrometerHBH, please make a PR on v0.13.0 branch like this, modify version to 0.13.0 on v0.13.0 branch.

[spectrometerHBH]

@ysh329 cc: #15216

[ysh329]

Hi all, this PR #15216 about modifying the version recorded to v0.13.0 on v0.13.0 branch is blocked by CI, but this won't block our cherry-picking soft deadline and cherry-picking hard deadline.

cc @driazati

[ysh329]

Hi all, this PR #15216 about modifying the version recorded to v0.13.0 on v0.13.0 branch is blocked by CI, but this won't block our cherry-picking soft deadline and cherry-picking hard deadline.

cc @driazati

Can anybody help to see the CI issue? It seems these thing block the process of release schedule several times.

[ysh329]

Hi all, this PR #15216 about modifying the version recorded to v0.13.0 on v0.13.0 branch is blocked by CI, but this won't block our cherry-picking soft deadline and cherry-picking hard deadline.
cc @driazati

Can anybody help to see the CI issue? It seems these thing block the process of release schedule several times.

Hi all, this Jenkins CI issue is about our Jenkins config for those non-main branchs will merge with latest main when CI running, this has no relation with Github branch protection.

Besides, this CI issue exposes our release step about version modification having some latent problem. We should modify version to 0.13.0 on main branch first and then do v0.13.0 branch cutting from main.:

• First, modify version to 0.13.0 on main branch first can avoid Jenkins CI conflict on Github between main and non-main branch, especially for one file in two branch existing divergence;
• Second, downstream companies codes are regulary git merge with release branch. If release version number modification is introduced on main, downstream companies can avoid locally conflicts about version number when git merge this release branch codes based on last release branch codes.

[tqchen]

I think the issue is that the PR always assumes merge with main in that Jenkinsfile