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.