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

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

Great info! Thanks!

On Apr 20, 2018, at 9:52 AM, Greg Stein <gstein@xxxxxxxxx> 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 :-)