> Am 12.09.2018 um 14:48 schrieb Jim Jagielski <j...@jagunet.com>: > > As I said before, the main assumption in my suggestion is that there are > things in trunk that "really should" be in some releasable version, stuff > significant enough to warrant the work, but is "impossible" to be backported > to 2.4. > > If there are no real significant-but-impossible-to-backport features in > trunk, then the proposal itself is moot. > > So let's think about it: What is currently in trunk that is a pretty > significant improvement? Then ask if it is directly backportable. Certainly > the effort in backporting from trunk to 2.4.x is much less than the effort in > spinning out 2.6.x and considering all things, that should be the primary > flow.
There are things I'd like to do for 2.5.x-to-become-2.6 releases that I cannot to in 2.4.x and will not do before that. I assume this holds also true for others. To put it another way: current trunk is dead code to me. Only a stopover for 2.4.x (aka release version). For the last three years, it was just in the way. Or another way: I am too old to commit to trunk only. ;) -Stefan
