[RFC] v0.7 Release Planning

[tqchen]

Thanks to everyone who works hard in the past cycle. This RFC to plan for v0.7 release. The community has always been focusing on high quality releases.

One of the major highlights in the past cycle is that we have gone through major refactors to make sure we have a fresh new foundation for new things we want to develop, and there are also exciting new features such as auto scheduler and uTVM coming in.

Considering the nature of the new foundational change, we propose to focus of this release on landing key foundational changes we have made -- for example the new TIR/target and pass infra, since they affect the API itself.

Because we are landing new features at a fast pace, we might include experimental features(that does not affect API itself) that may still need stabilization and work to cut another release after these features stabilize. We would include auto_scheduler(ansor) and intitial uTVM would be part of this release as experimental features and we will continue to polish the features in the incoming cycle.

Please share your thoughts.

In the next few days we will be populating the release note in this thread. Most release note content will be derived from our monthly report.

[tqchen]

@ZihengJiang and @zhiics have kindly agreed to serve as release managers for this release

[junrushao]

Do we have a target date for the release?

[tqchen]

Of course the the date would depends on the status of the release, because we should always aim for quality. Based on our past experience, it might takes a few weeks.

[comaniac]

1. Is the error reporting feature included in this release as an experimental feature or it would be in the next release?

2. For the experimental features, auto_scheduler and uTVM, would that be better to decorate their entry points with something like @experiment so that it pops a warning to tell users this feature is experimental (and maybe the actions we expect users to take when they encounter issues)?

[jroesch]

@comaniac if we land the final error reporting PR it removes the existing error reporting from type checker completely, I think we should either choose to ship it this release or delay until next release. One worry is that there will probably be a period of stability where we iterate/polish on new errors.

[comaniac]

@comaniac if we land the final error reporting PR it removes the existing error reporting from type checker completely, I think we should either choose to ship it this release or delay until next release. One worry is that there will probably be a period of stability where we iterate/polish on new errors.

Make sense to me (including the worry as well). Different from auto_scheduler and uTVM, error reporting is not just a standalone module that users can completely ignore, so we should be more careful.

[tqchen]

I agree that we should mark certain features as initial support/experimental in the release note. We could also come up with documentation tags to mark the feature as experimental. I am less certain sure about shooting a warning for each function call, as they harm the overall user experience, perhaps we can start with the release note and docs?

[zhiics]

Yeah, I also prefer to document it instead of throwing many warnings. In addition, we have some checker in the codebase claiming that some APIs will be deprecated in the next release. We probably want to take some actions on them as well.

[u99127]

I'd like to see the tvmc work to be functional before we cut the release please. I'd also like to see the Ethos-N PRs land as well.

[ZihengJiang]

@apache/tvm-committers @jroesch @u99127 @comaniac

We have a release note candidate here: #6486

Please comment it if you have anything want to be added into this release or other opinion.

[tqchen]

Let us plan to cut a release next week. At this point we should consider "freeze the features", but please suggest a list of PRs(fixes) that need to be merged.

[comaniac]

A brief summary of the related PRs missed in the current release note candidates. Not sure if all of them have to be listed so just for reference. Except for the note followed by the PR indicating its status, all PRs listed here are merged.

Automatic Scheduling (Experimental)

• [AutoTVM][Ansor] Enable random fill and CPU cache flush for AutoTVM and Ansor ([AutoTVM][Ansor] Enable random fill and CPU cache flush for AutoTVM and Ansor #6391)
• [Minor] Fix typos in Ansor ([Minor] Fix typos in Ansor #6425)
• [TUTORIAL][ANSOR] Using the template-free auto-scheduler on CPU ([TUTORIAL][ANSOR] Using the template-free auto-scheduler on CPU #6488)
• [ANSOR] Auto-scheduler tutorial for GPU and necessary refactor/fix ([ANSOR] Auto-scheduler tutorial for GPU and necessary refactor/fix #6512)
• [Ansor] Parallel the InitPopulation ([ANSOR] Auto-scheduler tutorial for GPU and necessary refactor/fix #6512)
• [Ansor][FLAKY] Bug fix for compute at mutation error ([Ansor][FLAKY] Bug fix for compute at mutation error #6557)

BYOC

• [BYOC][ETHOSN] Introduce further operator support ([BYOC][ETHOSN] Introduce further operator support #6355)
• [BYOC][JSON] Support input nodes with multiple entries ([BYOC][JSON] Support input nodes with multiple entries #6368)
• [BYOC][ACL] Add maximum support for float32 ([BYOC][ACL] Add maximum support for float32 #6506)
• [BYOC][ACL] Support add operation ([BYOC][ACL] Support add operation #6532) -- expected to merge in 1 week.
• [BYOC][ETHOSN] Fix tests for new module API ([BYOC][ETHOSN] Fix tests for new module API #6560) -- expected to merge in 1 week.

TVMC(Experimental)

• [tvmc] Introduce 'tune' subcommand (part 3/4) ([tvmc] Introduce 'tune' subcommand (part 3/4) #6537) -- expected to merge in 1 week.
• TVMC part 4/4: Tutorial -- not filed yet but I suppose it's required if we list TVMC as an experimental feature in 0.7 (cc @leandron, @u99127).

[tqchen]

At this point, we should focus on stablization, so we don't have to rush in features like Vitis-AI and TensorRT and can do them in the v0.8 cycle(for better stablization). We should instead list PRs that contains necessary fixes that need to be inlcuded.