> 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.
If a backports branch, e.g. cassandra-5.1 was in leu of both trunk alpha releases and a releasable trunk, then a rebase to it from cassandra-5.0 is one step closer to trunk. e.g. the work of rebasing and testing both jdk21 and cep-37* are done, and makes the next step to trunk (when it offers its first release) easier. The more we break up the steps the easier it gets, IMO. The balance here for the project is how do we do this in a way that balances the trade-off costs. This is also in the context where with or without a backports branch forks are not qualifying trunk. If we release trunk more often, if we put more effort into a releasable trunk, and/or make monthly/quarterly alpha releases off trunk, and get people actually qualifying trunk that's obviously better (as Josh has already well illustrated). And I do see the benefits of a releasable trunk to be numerously more (but it's also a lot more work to get there). *) jdk21 and cep-37 in a backports cassandra-5.1 isn't the best example here, if we come to agreement that they can go into cassandra-5.0. But they're used just as the theoretical example, you get my drift i hope.
