Thanks for the detailed proposal. I agreed with the policy and steps 1 to 7. After more people agreeing on the policy, I think we should document the policy somewhere.
Best regards, Jiadong On Fri, May 22, 2026 at 10:03 PM Yicong Huang <[email protected]> wrote: > Subject: [DISCUSS] Release branch naming, next release version, and release > cadence > > Hi all, > > Now that we have completed the v1.1.0-incubating release (congrats to > all!), I would like to start a discussion on our release process going > forward. > > TL;DR: I suggest that we use release branches for maintenance lines, tags > for exact releases, cut the next normal release as v1.2.0-incubating from > main, and aim for one minor release every three months. > > There are three related but separate topics: > > 1. Branch naming > 2. Next release version > 3. Release cadence > > > 1. Branch naming > ---------------- > Current branch: > release/v1.1.0-incubating > > Suggested convention: > release/v1.1 > release/v1.2 > release/v1.3 > > Exact releases should be represented by tags: > v1.1.0-incubating > v1.1.1-incubating > v1.2.0-incubating > > In other words: > release/v1.1 -> maintenance branch for the v1.1.x line > v1.1.0-incubating exact release tag > > release/v1.2 -> maintenance branch for the v1.2.x line > v1.2.0-incubating exact release tag > > If we later need a patch release for v1.2, we can merge safe patch commits > into release/v1.2 and create a new tag: > v1.2.1-incubating > > This gives us the freedom to create patch releases without creating a new > branch for every patch version. It also keeps the semantics clear: branches > represent release lines, and tags represent exact releases. > > > 2. Next release version > ----------------------- > I think we have two choices. > > Option A: v1.1.1-incubating > > Branch: release/v1.1 (renamed from release/v1.1.0-incubating) > Type: patch release > Scope: small, safe fixes only > > This should be used only if we want to fix the existing v1.1.0 line. > Examples include critical bug fixes, release packaging fixes, Docker image > fixes, security fixes, or other small non-breaking fixes. We do need to fix > a few things from 1.1.0-incubating, such as the NOTICE FILE ( > https://github.com/apache/texera/issues/5157). > > We should avoid breaking changes or large refactors in v1.1.1-incubating. > > Option B: v1.2.0-incubating > > Branch: cut release/v1.2 from main > Type: minor release > Scope: normal development after v1.1.0 > > This should be used if we want to release the current state of main. Since > we have made many substantial changes after cutting v1.1, including > refactors and bug fixes, v1.2.0-incubating is the more appropriate version > for the next normal release. > > My suggestion: go directly to v1.2.0-incubating for the next release, > unless we discover a critical issue that specifically needs a v1.1.x patch > release. > > > 3. Release cadence > ------------------ > My suggestion is: > > Minor release: every three months > Patch release: only when needed > > This gives us a predictable release rhythm without making the process too > heavy. It also helps us avoid letting too many changes accumulate between > releases. > > Patch releases should be reserved for urgent fixes to an existing release > line. > > > Proposed policy > --------------- > - Use release branches for maintenance lines, such as release/v1.1 and > release/v1.2. > - Use tags for exact releases, such as v1.1.0-incubating and > v1.2.0-incubating. > - Use patch releases only for safe fixes to an existing release line. > - Use minor releases for normal releases from main. > - Aim for one minor release every three months. > > > Concretely, I suggest the following next steps: > -------------------- > 1. Rename release/v1.1.0-incubating to release/v1.1. > 2. Make sure v1.1.0-incubating exists as a tag on the approved release > commit. > 3. On June 1, 2026, cut release/v1.2 from main branch. > 4. Prepare v1.2.0-incubating release candidates from release/v1.2. > 5. After approval, tag the approved release commit as v1.2.0-incubating. > 6. Use release/v1.2 for possible future v1.2.x patch releases. > 7. After v1.2.0-incubating, we wait for 3 months before cutting > release/v1.3 branch. I.e., we will cut v1.3 on Sept 1st, 2026. > > What do you think? > > Best regards, > Yicong Huang >
