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
