John Swinbank thank you for your review. I'm not attached to that process and I'm happy to talk about it. The constraints I have are:
- How does .lsst.io web site know which version it is meant to show by default? Looking for tags on release branches to try to guess seems more flaky than "most recent tag on master".
- If master is for "next version", how do we deal with a hotfix to the baselined document if some other major rewrite is ongoing? What if there are two rewrites ongoing? (as has almost happened with DPDD)?
Of course, we could treat this as a test case for how we would handle code releases in general if we have to keep an old release branch active whilst developing new code for the next release. If we adopted that policy for these change-controlled documents then that would be a win (and we still have to solve the "latest official release" problem for .lsst.io). I've copied Wil O'Mullane in and I'm sure Frossie Economou will have thoughts on this.
One option is to stick with the status quo of "master is baseline" until the release manager turns up.