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