0 No strong opinion -- Best Regards, Kunwoo (Chris) Park
---------------------------------------------------------------------------- Kunwoo (Chris) Park *He/Him/His* Ph.D. Student Donald Bren School of Information & Computer Sciences 2059 Bren Hall (949) 413-5324 ---------------------------------------------------------------------------- 2026년 5월 25일 (월) 오후 4:56, Ryan Zhang <[email protected]>님이 작성: > +1, this is consistent with how other open source projects manage their > releases, I am in favor. > > Thanks, > Ryan > > > > On Mon, May 25, 2026, 4:32 PM Chen Li <[email protected]> wrote: > > > Her's my vote: > > > > [X] +1 Adopt this release branch naming, next release version, and > release > > cadence plan > > > > On Mon, May 25, 2026 at 12:01 PM Yicong Huang <[email protected]> > > wrote: > > > > > Hi all, > > > > > > Following the discussion thread "[DISCUSS] Release branch naming, next > > > release version, and release cadence > > > < > > > https://urldefense.com/v3/__https://lists.apache.org/thread/yydt24r72vosbfbycnp43q3slkngvmsh__;!!CzAuKJ42GuquVTTmVmPViYEvSg!KvkHDiKHPiOq2B6_GZazSHjJAPUEMiVyPHhUFShuY958BfyqcTfmyncLqtoVnzcj7bmY2Yu--K5UeA$ > > >", I > > > would like to start a vote on the proposed release policy and next > steps. > > > > > > The proposal is: > > > > > > 1. Use release branches for maintenance lines. A release branch > > represents > > > a release line, such as the v1.1.x line or the v1.2.x line. For > example: > > > release/v1.1 > > > release/v1.2 > > > release/v1.3 > > > > > > 2. Use tags for exact releases. A tag represents the exact commit on a > > > release line used for a specific release. For example: > > > v1.1.0-incubating > > > v1.1.1-incubating > > > v1.2.0-incubating > > > > > > 3. Use patch releases only for safe fixes to an existing release line. > > > For example, if we need a future patch release for the v1.1 line, we > > can > > > merge safe fixes into release/v1.1 and tag the approved release commit > as > > > v1.1.1-incubating. > > > > > > 4. Use minor releases for normal releases from main. We will discuss > when > > > to bump major versions (i.e., 2.0.0) separately. > > > For the next normal release, we will cut release/v1.2 from main and > > > prepare v1.2.0-incubating release candidates from that branch. > > > > > > 5. Aim for one minor release every three months. > > > > > > Concretely, the proposed next steps are: > > > - Rename release/v1.1.0-incubating to release/v1.1. > > > - Make sure v1.1.0-incubating exists as a tag on the approved > release > > > commit. > > > - On June 1, 2026, cut release/v1.2 from main. > > > - Prepare v1.2.0-incubating release candidates from release/v1.2. > > > - After approval, tag the approved release commit as > > v1.2.0-incubating. > > > - Use release/v1.2 for possible future v1.2.x patch releases. > > > - After v1.2.0-incubating, wait about three months before cutting > > > release/v1.3, targeting September 1, 2026. > > > > > > Please vote: > > > > > > [ ] +1 Adopt this release branch naming, next release version, and > > release > > > cadence plan > > > [ ] 0 No strong opinion > > > [ ] -1 Do not adopt this plan, with reason > > > > > > This vote will remain open for at least 72 hours. > > > > > > > > > And I will start with my own +1. > > > > > > Best regards, > > > Yicong Huang > > > > > >
