+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 > > >
