o 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
t; reading some of that could be helpful when read as a comparative point to
> how HTTPD historically does its T and branch/release management. That
> Subversion "manual" on releases is very stable, and what we've been
> doing/developed during our 18 years, especially wi
ead as a comparative point to how
> HTTPD historically does its T 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 vers
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 and branch/release management. That
Subversion "manual" on releases is very stable, and
On Wed, 20 Aug 2014 16:35:34 +0100
Ben Reser b...@reser.org wrote:
I'd do the rolling myself but I'm not 100% clear on what needs to
happen. So if someone can do a little hand holding I'll be happy to
do the release myself. I'm generally familiar with how the ASF does
releases since I do the
