-
Notifications
You must be signed in to change notification settings - Fork 79
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
[RFC] Quarterly Releases #67
Changes from 6 commits
1d28f8a
b6fa24e
3699f34
2098725
66ef7c8
388a0fa
6f25a72
f799a37
0b49277
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,68 @@ | ||
- Feature Name: Release Schedule | ||
- Start Date: 2022-04-21 | ||
- RFC PR: [apache/tvm-rfcs#67](https://github.com/apache/tvm-rfcs/pull/67) | ||
|
||
# Summary | ||
This RFC proposes that TVM move to a quarterly release schedule. Releases would happen every 3 months or so on a schedule set well in advance, independent of individual feature development in TVM. | ||
|
||
# Motivation | ||
Releases are essential to the usage of TVM, especially now that are beginning to work on publishing binary packages for TVM under PyPi. Making TVM releases frequent forces the release process to become well documented and simple rather than bespoke and only achievable by a small group. Users benefit from releases by seeing that the the project is still under active development and providing an easy way to get new features. As of this RFC it has been five months since the last release. It could easily confuse new users when they expect some TVM feature that was only developed recently but is not present in the latest official release. | ||
|
||
|
||
# Guide-level explanation | ||
TVM has [release process documentation](https://tvm.apache.org/docs/contribute/release_process.html). This RFC proposes that a release candidate vote thread sent on a schedule roughly every three months. A release branch will be cut, evaluated for a period of two weeks, evaluated by the PMC, then a release published. Publishing a release entails: | ||
|
||
* Gathering and organizing release notes since the last release | ||
* Posting a source code release on GitHub | ||
* Uploading the source code to the Apache SVN repository | ||
* Uploading binary packages to tlcpack | ||
* Uploading binary packages to PyPi | ||
* Getting an approval vote from the PMC | ||
|
||
# Reference-level explanation | ||
|
||
Prior to a release a new, lightweight vote would instead be used to nominate a release manager, a committer who will be responsible for guiding along the release process. Releases will roughly match the quarterly [calendar dates](https://en.wikipedia.org/wiki/Calendar_year#Quarters) shifted two weeks earlier (Q1: mid March, Q2: mid June, Q3: mid September, Q4: mid December). The release manager will have final say on all dates and consideration should be given for their personal schedule. The timeline will be as follows: | ||
|
||
* Three weeks prior to the release | ||
* The release manager will cut a release branch and create a new tag | ||
* The release manager will audit the licenses of all project dependencies to ensure they are compatible with Apache | ||
* The release manager will open a GitHub issue announcing the release branch cut and target date for the release and state that any further inclusions in the release must be manually cherry-picked | ||
* The release manager will create a PR targeted to merge into the release branch with the necessary changes to make a release (i.e. changing version numbers) | ||
* Contributors that wish changes to be cherry-picked should comment on the announcement issue with the relevant PRs and commits and their reasoning. The release manager has final say on which changes should be included but should aim to be inclusive at this stage | ||
* The release manager begins gathering release notes | ||
|
||
* Two weeks prior to release | ||
* Cherry picks become limited to critical changes only | ||
* The release manager begins building binaries and testing them against TVM's test suite and running on relevant hardware | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What is the test suite? Is it anything beyond what the Jenkins tests already do? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not currently and this RFC intentionally doesn't specify it, we can iterate on release-specific tests more as we go through the process |
||
* The release manager sends the release notes and plan to a vote thread for approval (feedback thread will be open for one week) | ||
* The release manager performs another license audit of all project dependencies to ensure they are compatible with Apache | ||
|
||
* One week prior to release | ||
* The release manager sends the release and binaries to a vote thread for approval (thread open for one week). If rejected the building and test process must be started anew and repeated until the PMC approves. | ||
|
||
* Day of the release | ||
* The release manager publishes the relevant binaries, including the source `.tar` to Apache | ||
* The release manager closes the release issue | ||
* The release manager makes a GitHub release via a tag and updates an in-repo file `RELEASE.md` on both `main` and the release branch with the release notes | ||
|
||
Much of this can be automated via GitHub Actions on the apache/tvm repo. Eventually (though maybe not for the upcoming release) these will handle all the building, testing, and publishing of releases so the job of the release manager will become simpler over time. | ||
|
||
Developers are heavily encouraged to use feature flags and Python API conventions (i.e. prefixing unstable or private APIs with an underscore) to enable in-progress features. It is important both for users to be able to access new or experimental behavior but also that they can get a stable interface, so these kinds of changes should be hidden behind opt-in flags. | ||
|
||
Comment on lines
+50
to
+51
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Thanks @driazati, I think this specifically is a very positive move for TVM to make. I have encountered perception among developers that designs must be near-perfect before making it into TVM. I'm happy to see explicit language around experimental feature flags which explicitly encourage iterative design. I wonder about your and others opinion on whether we need a separate RFC to formalize the process around introducing experimental changes and their path to graduation into stable releases? Nonetheless this is great first step, thank you for outlining it. |
||
Even with this RFC the ultimate decision to releases rests with the community. If no one wants to do a release, then it will be skipped or delayed until the community agrees and a release manager can be selected. | ||
|
||
## Versioning | ||
The release manager will use the release notes and discussions with developers to determine the next version number. Releases will continue the current versioning scheme of `major.minor.patch`, with a typical release involving a bump of the minor release version. Patch versions will be used for follow up releases onto a quarterly release, but not for the next quarter's release. The release manager will be responsible for maintaining the release until the next release, which mainly entails putting up a patch release if necessary. The release manager may also delegate this responsibility to another party if both agree. | ||
|
||
# Prior Work | ||
|
||
* This [proposal](https://discuss.tvm.apache.org/t/pre-rfc-switch-to-time-based-releases/4245) suggests a similar thing for TVM and links to a great [write-up](https://cwiki.apache.org/confluence/display/KAFKA/Time+Based+Release+Plan) from the Kafka project describing their plan. | ||
|
||
# Drawbacks | ||
|
||
* This requires a high level of commitment from a single individual (the release manager). If someone is not able to fill or execute this role effectively the release will be stalled. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Perhaps we should also have a deputy, who's aware about what is going on, and in the absence of the release manger can take over. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. agreed that's a good idea but I don't think we need to explicitly codify that, if there is a problem with the release manager's time they should communicate that to the community and figure something out from there There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. To help mitigate with this, several projects stagger release managers, with an outgoing release manager and an incoming shadow release manager. This spreads out the responsibility and gives an opportunity to formally train someone on release management duties. |
||
|
||
# Rationale and alternatives | ||
|
||
* The main alternative is waiting until specific features have been developed in order to make a release. This has caveats as TVM has many sub-projects within it, so it's not clear which is significant enough to warrant a release. | ||
driazati marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shall we add a note about contributors testing the release on real hardware?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
added a short note about it but I don't want to expand the scope of this RFC too much, specific release testing instructions should be in https://tvm.apache.org/docs/contribute/release_process.html somewhere