You have listed some good points about two parallel tracks for development. Here are some drawback. 1. Will be expensive (not only on development, but in terms of community resources, think documentation, support, ...etc. as well as the obvious fragmentation of the development effort). 2. Confusing (communication to prospective and present users, as well as the development community). 3. Do we have to merge repositories at one point (4.8 branch to 5.0)? If not, then it is effectively maintenance on 4.7, with (possible/questionable) patch ports to 5.0. Having said that, point 1 may not be constrained by the development resource issue that it used to be, since we now have very capable and proven branch maintainers and commiters (Gerhard and Neil). In other words, this is not as much of a problem as it has been in the past where it was mainly Dries doing it all. Side point: I have stated before that 4.7 should have been 5.0, since we have significant APIs and functionality changes. The decision to stay with 4.7 and not call it 5.0 had good reasons (too late to call it something else). How about using a code name for the next release and not just a number? For example, if we call the next release any meaningless name such as Gizmo, or Orca, we can then decide before we release it to call it 4.8 or 5.0 depending on what went in.