(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 <j...@jagunet.com> wrote: > Great info! Thanks! > > > On Apr 20, 2018, at 9:52 AM, Greg Stein <gst...@gmail.com> 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 > [2] http://svn.apache.org/repos/asf/subversion/branches/ > [3] http://svn.apache.org/repos/asf/subversion/trunk/CHANGES > > > -- martin.langh...@gmail.com - ask interesting questions ~ http://linkedin.com/in/martinlanghoff - don't be distracted ~ http://github.com/martin-langhoff by shiny stuff
