git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Versioning, Release Management, Stabilization, etc ... Subversion style


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