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