I agree with these suggestions. Regarding "2. Next release version," I also agree with "Option B: v1.2.0-incubating."
We can start a vote. Chen On Mon, May 25, 2026 at 12:24 AM Yicong Huang <[email protected]> wrote: > 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 > > > >
