-
Notifications
You must be signed in to change notification settings - Fork 3.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Release] v0.13.0 release schedule #15134
Comments
Happy to help with some of the branch cutting works, Thanks @ysh329 for volunteering |
Thanks @ysh329. Happy to help with things that need permissions! |
I volunteer to help manage the release |
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.
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 I think these two things about I modified the schedule and add a step about |
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 |
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.:
|
I think the issue is that the PR always assumes merge with main in that Jenkinsfile |
I think branch protection is no problem, because the git merge operation is actually a protection mechanism for our publishing branch. Fundamentally, ensure that the PR introduced by the release branch is in the form of Cherry Pick on the main branch. And in theory, as long as the PR of cherry pick is in order introduced from main, there will be no conflicts on the publishing branch. The behavior of version modification on release branch was not in the form of Cherry Pick, and after branch cutting, we made changes on the main branch, which caused divergence thus conflicts. I think we can first modify the version number on the main branch next time, because two reason as above. |
Hi all, considering the originally scheduled voting day is a weekend, I'll advance voting day to this Friday (07/14/2023). Thus we need prepare release candidate packaging and uploading in advance. cc @Hzfengsy |
Hi all, v0.13.0 Release Candidate Notes published in advance: #15295 |
Please help prepare release candidate packaging and uploading for voting. |
Please help delete branch |
@ysh329 packages are ready now. |
I tested v0.13.0.rc0 and passed. Check sha512# Check sha512
$ shasum -a 512 ./apache-tvm-src-v0.13.0.rc0.tar.gz
da0fa8ad9a858b297fc1dc883a37505f6277e57568e9770a734b99ad34379d4bde6f7fde0d93a7ebf2454dd2086d9c1567e3768cd55bc50ca9749762628b89c0 ./apache-tvm-src-v0.13.0.rc0.tar.gz
$ cat ./apache-tvm-src-v0.13.0.rc0.tar.gz.sha512
da0fa8ad9a858b297fc1dc883a37505f6277e57568e9770a734b99ad34379d4bde6f7fde0d93a7ebf2454dd2086d9c1567e3768cd55bc50ca9749762628b89c0 apache-tvm-src-v0.13.0.rc0.tar.gz Check asc# Check asc
$ gpg --import ./KEYS
gpg: key 6754EA97C55E3DEB: "Tianqi Chen (CODE SIGNING KEY) <[email protected]>" not changed
gpg: key 8955D84E20C9AB0C: "Yizhi Liu <[email protected]>" not changed
gpg: key 3A709F6F2B86E9D6: "Yizhi Liu (Yizhi Liu at Apache) <[email protected]>" not changed
gpg: key CA751254E97B9FE4: "Yizhi Liu <[email protected]>" not changed
gpg: key ED03B26E4FC3509F: "Ziheng Jiang <[email protected]>" not changed
gpg: key 9FBECBD3D75EFD4B: "Zhi Chen <[email protected]>" not changed
gpg: key 35ABC9676004ADAE: "Junru Shao <[email protected]>" not changed
gpg: key 2C75E5A496C80880: "Wuwei Lin <[email protected]>" not changed
gpg: key 07FA463F1C926F48: "David Riazati <[email protected]>" not changed
gpg: key C9A56ABD5CCA3EB8: "Andrew Zhao Luo <[email protected]>" not changed
gpg: key 28D4862222B8EC31: "Leandro Nunes <[email protected]>" not changed
gpg: key 06D051CA84EF3749: public key "Siyuan Feng (CODE SIGNING KEY) <[email protected]>" imported
gpg: Total number processed: 12
gpg: imported: 1
gpg: unchanged: 11
$ gpg --verify ./apache-tvm-src-v0.13.0.rc0.tar.gz.asc ./apache-tvm-src-v0.13.0.rc0.tar.gz
gpg: Signature made Fri Jul 14 10:24:35 2023 CST
gpg: using RSA key 664EF29634C05669C3DCF83106D051CA84EF3749
gpg: Good signature from "Siyuan Feng (CODE SIGNING KEY) <[email protected]>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 664E F296 34C0 5669 C3DC F831 06D0 51CA 84EF 3749
$ gpg --edit-key 664EF29634C05669C3DCF83106D051CA84EF3749
gpg> trust
Your decision? 5
Do you really want to set this key to ultimate trust? (y/N) y
$ gpg --verify ./apache-tvm-src-v0.13.0.rc0.tar.gz.asc ./apache-tvm-src-v0.13.0.rc0.tar.gz
gpg: Signature made Fri Jul 14 10:24:35 2023 CST
gpg: using RSA key 664EF29634C05669C3DCF83106D051CA84EF3749
gpg: checking the trustdb
gpg: marginals needed: 3 completes needed: 1 trust model: pgp
gpg: depth: 0 valid: 3 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 3u
gpg: next trustdb check due at 2025-04-22
gpg: Good signature from "Siyuan Feng (CODE SIGNING KEY) <[email protected]>" [ultimate] Check binary# check binary
$ find ./apache-tvm-src-v0.13.0 -type f -exec file {} + | grep -w "ELF\|shared object"
# find nothing Compile and Python Import on LinuxPassed with default config. |
Hi all, vote starts (#15313). Everyone is welcomed to vote. Please vote by replying to this thread explicitly. Vote will close July. 20th at 23:59M GMT. |
Hi all, vote passes with #14844, next we'll 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. This program needs help please. Besides, we need update doc website too. According to last release talk as below, this step would need ASF perm.
Originally posted by @vinx13 in #14505 (comment) |
Hi all, let's persevere until the end. The sight of a great triumph is coming soon. cc @Hzfengsy @junrushao @vinx13 @tqchen |
I have Updated Github pre_release to release and also upload to the svn release folder |
Hi @vinx13 , can you help update docs to website? |
I've updated the website |
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:
v0.13.0
to be created frommain
v0.14.dev0
to be created, marking the beginning of the next development cyclev0.14.dev0
onmain
branch, Update version to 0.14.dev0 on main branch #15208v0.13.0
onv0.13.0
branch,[release] Bump version numbers to 0.13.0 #15216, [Release] Fix version number on branch v0.13.0 #15273Call 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:
cc @apache/tvm-committers @driazati @areusch @Mousius @tqchen @AndrewZhaoLuo
The text was updated successfully, but these errors were encountered: