On Thu, Jan 5, 2017 at 12:50 PM, Jacob Champion <champio...@gmail.com> wrote: > On 01/04/2017 11:55 AM, Graham Leggett wrote: >> >> On 04 Jan 2017, at 8:37 PM, Jacob Champion <champio...@gmail.com> wrote: >>> >>> So, there's 3k of the 20k. And remember, my point was that we can >>> fix what I call "dead code" with good old fashioned legwork. I >>> don't advocate trashing trunk, and I don't think having "dead code" >>> is a disaster or a stain on anyone here. I just don't think it's >>> appropriate to spin up an RC from trunk as-is. >> >> >> Look for the discussion that occurred around November 2011 when v2.4 >> was released: >> >> http://smtp.grokbase.com/t/apache/dev/11bb6wswq2/branched-httpd-2-4-x >> >> We came to the same conclusion then. > > > I started a longer reply to what you wrote earlier in the email, but I think > I need to clear up any misunderstandings I have with this part first. > > From offlist discussions I've had with other committers (and Bill's recent > reply to this thread), my understanding was that an alpha/beta branch would > be forked from the current tip of trunk, followed by testing and additional > feature work, until a .0 release is voted on. > > The conversation you linked to appears to modify that somewhat: we started > tagging trunk directly with alpha/beta, and at some point decided to fork a > 2.4.x from a mostly current trunk. It also adds the information that 2.4.x > was still CTR, up to the .0 release. But in both cases, the statement "we > plan to fork 2.6.x from a current-ish trunk commit" seems to hold up pretty > well. > > Is that correct?
Following past practices, and a desire to reduce the amount of effort by committers, I'd strongly object to a fork before 3.0 (or 2.6) is finalized. It's a procedural-process sort of question, so it's a straightforward PMC majority vote. I'm also against forking at 3.0 or 2.6 until someone wants to introduce an API breaking change, unless we solidify some new process for having more predictable and frequent bug fix releases and split these from our constant churn of feature changes. In that case, feature changes do map well to trunk until there is a breaking ABI change, while we would need to collect such bug fixes on a new branch.
