+1 Best regards, Jiadong
On Mon, May 25, 2026 at 4:58 PM Kun Woo Park <[email protected]> wrote: > 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 > > > > > > > > > >
