> Well, Darrell and others make a good argument for creating a 14.0.0 branch at
> RC1. Development continues on head/master and only critical/blocker fix commits
> (and any cherry picks from continued development) can be merged into the 14.0.0
> branch for RC2 and then one more cycle for the release.

Well, that was the idea basically. In more detail:
1) once we think we are ready, we tag RC1. 
2) work can continue as usual on the main trunk, but new changes will not make it to R14.0.0
3) any patch that is related to R14.0.0 (blocker, critical bugs) will have to be backported to the RC1 branch.
4) once we are ready, RC1 will turn into RC2 and eventually RC3
5) once we are happy, we tag R14.0.0, then build and release (which is probably going to take one and half months anyway)

If this schema is in place, we could even tag RC1 today, even though I think Darrell still has some changes to the help handbook main structure that he would like to complete before that.
  Michele