A useful, well-documented process of a fellow Apache community ... a process that has worked steadily and produced (your words) "outstanding stability, backwards compat, and steadily add new features, big and small".
We're talking process, not the merits of software package that uses it (and this isn't the place to argue svn's merits). Frankly, HTTPD does not have a well-documented process to balance stability, compatibility, and progress. Leveraging svn's process could be helpful, with some tuning specific to the httpd community. Cheers, -g On Fri, Apr 20, 2018 at 4:18 PM, Martin Langhoff <martin.langh...@gmail.com> wrote: > (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 >
