git.net

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

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


(as a completely external voice, user, packager, architect of systems big and small) - would it not make sense to model the workflow of a project that has a more positive feature _and_ stability profile?

With all due respect, Subversion is an old project, offering little new, with a dwindling userbase. New adoptions of subversion are not something you hear about.

I would instead look at git -- not because it's an SCM, but because it's a smaller, simpler, and less "personality-driven" version of the Linux kernel workflow. Or PostgreSQL, which is evolving towards something similar but even less personality-driven.

Both git and Pg offer really outstanding stability, backwards compat, and steadily add new features, big and small. Every time I look I am pleasantly surprised of the new bits added.

with high regards, and respect,



martin

On Fri, Apr 20, 2018 at 10:05 AM, Jim Jagielski <jim@xxxxxxxxxxx> wrote:
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 :-)

Cheers,
-g






--
 - ask interesting questions  ~  http://linkedin.com/in/martinlanghoff
 - don't be distracted        ~  http://github.com/martin-langhoff
   by shiny stuff