Great info! Thanks!
> On Apr 20, 2018, at 9:52 AM, Greg Stein <[email protected]> wrote:
>
> Hi all,
>
> I've been kind of watching the thrashing around on several threads now about
> problems and fixes to how the HTTPD project manages its process around
> releases. I thought it might be a good idea to suggest a tried-and-true
> alternative defined by the Apache Subversion project, and documented
> extensively at [1].
>
> That is a lot to wade through, and parts just don't apply ... but even
> reading some of that could be helpful when read as a comparative point to how
> HTTPD historically does its T&R and branch/release management. That
> Subversion "manual" on releases is very stable, and what we've been
> doing/developed during our 18 years, especially with the project's
> understanding of version control, and svn specifically :-)
>
> Read the "Stabilizing and maintaining releases" section at a minimum, please.
> That is kind of core to some of the issues on the mailing list recently, and
> it describes how Subversion does things.
>
> I don't want to write a tome, but to begin a discussion to adopt that
> documented approach with tweaks for httpd. So to write a shorter note, I'd
> basically summarize as:
>
> * all development occurs on trunk
> * release branches are made off trunk for each MINOR release (see the 1.$N.x
> branches at [2])
> * stabilization occurs on release branches by only cherry-picking existing
> work/changes off of trunk
> * when a release branch is made, trunk's version is bumped (ie. say trunk is
> 2.5, the 2.6.x branch is made, then trunk becomes 2.7)
> * IMO, don't bother making 2.7.x releases; just use the number to determine
> if somebody grabbed a snapshot of trunk (svn happens to be 1.11.0-dev in
> trunk, and will become 1.12.0-dev once the 1.11.x branch is made; the svn
> project looks for a reported version of "-dev" for such snapshot behavior)
> ... if you're going to think about a 2.7.x "test" release, then just make it
> 2.8.x instead and label the feature experimental.
> * trunk is always stable and passes buildbot tests
> * version numbers are cheap, feel free to burn them (see our CHANGES[3] where
> many specific numbers are recorded as "Not released")
> * Subversion has its own compatibility declarations defined around
> major/minor; I'd suggest skip that and stick to the existing HTTPD "MMN"
> system
>
> I think that is most of the highlights. Again: I'd suggest reading the
> section on Stabilization, and maybe "Creating and maintaining release
> branches" section. The whole page for extra credit :-)
>
> Cheers,
> -g
>
> [1] http://subversion.apache.org/docs/community-guide/releasing.html
> <http://subversion.apache.org/docs/community-guide/releasing.html>
> [2] http://svn.apache.org/repos/asf/subversion/branches/
> <http://svn.apache.org/repos/asf/subversion/branches/>
> [3] http://svn.apache.org/repos/asf/subversion/trunk/CHANGES
> <http://svn.apache.org/repos/asf/subversion/trunk/CHANGES>
>
