@u99127 these are great points! i have some thoughts: > Lifecycle of a release , what happens to a release x.y.0 after the release > point ? The community has 2 choices, use frugal release manager resources in > making sure the next (x.y.0)+1 release happens on schedule and on time . Or > continues to improve the quality of x.y.0 by fixing bugs and making sure that > x.y.1 / x.y.2 keep happening - but then after a year we'll have too many > releases and given where we are in the lifecycle of TVM, this may not be > necessary.
It seems like there may be a difference between a 1.0 release and a 0.x release in terms of support. Perhaps a 0.x release is patch-supported for a short time (e.g. until the next release cycle starts)? > At what point do we declare an old release something that the community will > not support further ? i.e. x.y.0 is valid for 6 months or a year after which > there will be no releases from the branch and the community will not take any > bug fixes into the branch ? yeah this is a great question. it seems like right now our policy is to "support" the previous release and no further back. also something i'd expect to grow or perhaps we'd arrive at an LTS-style support policy depending on development cadence. > Are release managers appointed for the life cycle of a 0.x release - i.e is > it the responsibility to keep 0.x until its end of life ? it could be good to state that a release manager is expected to shepherd questions (though the entire set of committers and community is expected to try and answer without the need for shepherding) about the release on the forum. i'd propose we start with a shorter support period so it is not overly daunting to be a release manager. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/67#issuecomment-1113516331 You are receiving this because you are subscribed to this thread. Message ID: <apache/tvm-rfcs/pull/67/c1113516...@github.com>
