On Tue, Nov 7, 2017 at 6:35 AM, Daniel Ruggeri <drugg...@primary.net> wrote: > This is open for discussion. My opinion: For Alpha, I think it makes sense > to tag from trunk rather than branching first. That is, delay the branching > as long as possible so 2.6 looks as close to trunk for as long as possible. > This keeps the APIs in sync as well as avoids unnecessary process to > backport changes to Alpha. That is not a hard and fast rule, of course. If > we want to begin work on a major overhaul we'd consider too disruptive, then > we should branch.
+1... in theory we eventually approve a beta, at that point we probably want to branch for stability. But thinking more broadly, big changes should first be presented to dev@... so do we consider branching trunk to demonstrate some substantial API change, and simply merge it back when accepted? That would be a way to preserve dev's ability to propose future api changes before trunk becomes 2.7.0-dev. If you are thinking of n.n.n-alphan format, how is that going to be mapped within ap_release.h? Version numbers are cheap, so cycling n.n.n-alpha to n.n.n+1-alpha hasn't proven to be an issue.
