> > I agree with the concerns you raise around feature rot. For a feature like >> EC, it'd be untenable to leave it in trunk-incompat since the rebases would >> be impossible. I imagine we'd also need a very motivated maintainer (or >> maintainers) to handle the periodic integration of new trunk commits, since >> you'd potentially be doing it for multiple large features. If some brave >> and experienced committer is willing to own maintenance of the >> trunk-incompat branch, I think it could work. However, this is a big shift >> from how we've historically done development. >> > > If an incompatible feature is ready (like EC here), should we consider > working towards the next major release? In other words, is it okay to defer > cutting branch-3 until we have a large incompatible feature that would be a > pain to keep up with? >
So the idea is that we do trunk-incompat, then when the first large incompat feature hits, we switch to branch-3? I guess this might work, though it still requires someone to maintain trunk-incompat. I think it'd also be hard to make this decision, since EC for instance at one point was targeted for 2.x.
