> Both the ideas of a back port branch and monthly/quarterly alpha releases > from trunk (which is a variant of the notion of releasable trunk) provide > ways to bring forks closer to trunk.
I do see how frequent alpha releases make it easier to qualify and subsequently adopt trunk, and am fully in favour of cutting more frequent releases. Could you elaborate how back porting features from trunk to other branches incentivise adoption? So far from the conversation I got an impression that folks are asking for backports branch to avoid adopting trunk, stick to known set of moving parts, and save time by avoiding qualifying trunk. On Sat, Oct 25, 2025, at 12:48 AM, Mick wrote: > > > > On 24 Oct 2025, at 23:43, Jeremiah Jordan <[email protected]> wrote: > > > > Or at the least letting our fork more closely follow trunk, rather than > > following a previous GA branch, with us only needing to put things in the > > fork that only make sense because of the DBaaS bits. > > > Both the ideas of a back port branch and monthly/quarterly alpha releases > from trunk (which is a variant of the notion of releasable trunk) provide > ways to bring forks closer to trunk. So a back port branch would in fact > be useful to DataStax, but limited value compared to alpha releases off trunk > and especially a releasable trunk. > > One of my observations is the rebasing from one GA branch to the next has a > cost and uncertainty that increases disproportionately the biggest the diff > between those GA branches are. Being able to rebase more often but in > smaller more incremental steps would end up being less work and more > predictable. I would say the release early, release often mantra applies > equally to forks as it does operators.
