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 [2] http://svn.apache.org/repos/asf/subversion/branches/ [3] http://svn.apache.org/repos/asf/subversion/trunk/CHANGES
