+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 > > >
