You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Greg Stein <gs...@gmail.com> on 2018/04/20 13:52:32 UTC
Versioning, Release Management, Stabilization, etc ... Subversion style
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
Re: Versioning, Release Management, Stabilization, etc ... Subversion style
Posted by Greg Stein <gs...@gmail.com>.
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 <ma...@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 <ji...@jagunet.com> wrote:
>
>> Great info! Thanks!
>>
>>
>> On Apr 20, 2018, at 9:52 AM, Greg Stein <gs...@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.langhoff@gmail.com
> - ask interesting questions ~ http://linkedin.com/in/martinlanghoff
> - don't be distracted ~ http://github.com/martin-langhoff
> by shiny stuff
>
Re: Versioning, Release Management, Stabilization, etc ... Subversion style
Posted by Martin Langhoff <ma...@gmail.com>.
(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 <ji...@jagunet.com> wrote:
> Great info! Thanks!
>
>
> On Apr 20, 2018, at 9:52 AM, Greg Stein <gs...@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.langhoff@gmail.com
- ask interesting questions ~ http://linkedin.com/in/martinlanghoff
- don't be distracted ~ http://github.com/martin-langhoff
by shiny stuff
Re: Versioning, Release Management, Stabilization, etc ... Subversion
style
Posted by Jim Jagielski <ji...@jaguNET.com>.
Great info! Thanks!
> On Apr 20, 2018, at 9:52 AM, Greg Stein <gs...@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 <http://subversion.apache.org/docs/community-guide/releasing.html>
> [2] http://svn.apache.org/repos/asf/subversion/branches/ <http://svn.apache.org/repos/asf/subversion/branches/>
> [3] http://svn.apache.org/repos/asf/subversion/trunk/CHANGES <http://svn.apache.org/repos/asf/subversion/trunk/CHANGES>
>