Hi all, Following the discussion thread "[DISCUSS] Release branch naming, next release version, and release cadence <https://lists.apache.org/thread/yydt24r72vosbfbycnp43q3slkngvmsh>", 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
