Are there any further comments or concerns? If not, I will start a vote on the proposed plan tomorrow. Thanks.
Best, Yicong Huang [email protected] On May 23, 2026 at 10:27 -0700, Jiadong Bai <[email protected]>, wrote: > 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://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Ftexera%2Fissues%2F5157&data=05%7C02%7Cyiconghuang%40umass.edu%7Cd220dc693a7d49fc6a0c08deb8f080b8%7C7bd08b0b33954dc194bbd0b2e56a497f%7C0%7C0%7C639151540272794310%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=5mK8nnHL%2Bk0QnzC%2F9FEV7yoFjUZAeHPe76SIbirvx8o%3D&reserved=0). > > > > 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 > >
