+1 to the proposal. Jaydeep
On Fri, Nov 14, 2025 at 2:49 PM Caleb Rackliffe <[email protected]> wrote: > +1 to the proposal > > > *We reserve the right to release more frequently than this if we decide > to* > > MAJOR.MINOR? Would keep oldest GA for a predictable length with support > model but introduce a new branch into our merge-path which is extra merge > and CI toil. > > Or new MAJOR and we drop oldest supported? If we cut alphas (see below), > the pressure for out-of-cycle releases to make features available may be > mitigated. > > If we really want to do this, it feels reasonable to say it should be > something important enough to force a new MAJOR, drop the oldest > supported major, and "reset" the "alpha clock" back to 1. Otherwise, making > it into the next scheduled alpha and then the following MAJOR on a 12-month > boundary should be fine. The nightmare scenario for that, though, is when > we want to do it in, let's say...February, while the Jan 1 MAJOR is in > beta. Maybe it's better to just avoid it. > > On Thu, Nov 13, 2025 at 2:30 PM Josh McKenzie <[email protected]> > wrote: > >> What I mean is if we decide the train leaves the station on December 1, >> how do we choose the features on the train? >> >> Features merged to trunk should be in one of the following 3 states: >> >> 1. alpha: Not exposed to users if they don't yet work (available via >> .yaml config maybe, etc) >> 2. beta: Exposed but flagged as experimental and off by default >> 3. ga: Exposed and available by default (barring any guardrails, etc) >> >> So whatever features are committed and beta before that date are in the >> release and available at varying levels of ease to our users. No need to >> decide what goes into a release since, worst-case, you merge a ga feature >> to trunk 1 day after we froze and it's available via the next alpha in 3 >> months. >> >> I'm using alpha / beta / GA above in a somewhat new way for us that >> reflects what we've *actually* been doing. I think using the same >> alpha/beta/GA hierarchy for features as we use for releases would help >> provide consistency and symmetry for user expectations, but that's another >> topic I plan to bring up after we get alignment here. >> >> On Thu, Nov 13, 2025, at 2:59 PM, Brandon Williams wrote: >> >> On Thu, Nov 13, 2025 at 1:55 PM Patrick McFadin <[email protected]> >> wrote: >> > >> > What I mean is if we decide the train leaves the station on December 1, >> how do we choose the features on the train? >> >> They are committed before the train leaves, or they have to wait for >> the next one. >> >> Kind Regards, >> Brandon >> >> >>
