Michael Sperber writes:
It's a process question: If you branch off later, you'll have
development and bug fixes mixed, and that can't be easily separated
after the fact.
I don't understand. Perhaps the code committed in post-GPLv3
revisions will be hard to include for the reason you give, but you can
still conveniently work around those revisions by branching from an
earlier version at any date. It seems to me that it's a better idea
to make the decision which version to branch from *after* seeing the
later development, rather than possibly creating a dead branch early
because we later realize that "oh, we should include all this good
stuff" and go create another release branch.
There will be bug fixes mixed in with the aggressive development in
any case (unless you close the development branch). I would rather
not have to watch both branches for bug fixes and be cherrypicking
(*not* merging! only Darcs can merge individual patches, all other
VCSes lose dependency and conflict information) in both directions.
 It's possible that svnmerge.py could be adapted to Mercurial, but
according to the folks working on Python's migration to Mercurial it
hasn't been done yet. This would mitigate the problem, but add a
burden of new process.
XEmacs-Beta mailing list