releases, branching, etc

[Paul Querna <pa...@querna.org>]

This stems out of a discussion we had at ApacheCon about how best to
do releases and create stability for Traffic Server.

httpd's VERSIONING:
<https://svn.apache.org/repos/asf/httpd/httpd/trunk/VERSIONING>
This document explains how httpd is trying to balance maintaining a
stable version used by millions, and at the same time introduce new
features quickly.  I believe TS would benefit from adopting a similar
philosophy on stability of APIs.

httpd's release Q&A:
<http://httpd.apache.org/dev/release.html>
This document covers in Q&A style various bits of info on how HTTPD's
releases are done.

The tools httpd uses to make a release are here:
<https://svn.apache.org/repos/asf/httpd/site/trunk/dist/tools/release.sh>

It would also be good to get TS building in CI, if someone has time
you should mail infrastructure@ and work to get it all setup:
<http://ci.apache.org/>

Any questions I can answer?

-Paul

Re: releases, branching, etc

["Roy T. Fielding" <fi...@gbiv.com>]

On Nov 9, 2009, at 3:53 PM, John Plevyak wrote:

> This leapfrog process has a lot of theoretical draw, and it is the  
> one that Linux tried
> but because the experimental line became a dumping ground for  
> unstable code and
> more code built upon it, the time between "stable" releases became  
> so long that all
> the major stakeholders ended up doing significant backporting. I  
> don't think it can be
> considered a success.  If someone knows a project which has used  
> this model successfully
> (for several years) I would be interested in knowing about it.
> Alternatively, there is the 6 month stable model.  In particular  
> there the OpenBSD variant
> which has a window for feature lock and a short all-hands release  
> press:
>
> http://www.youtube.com/watch?v=i7pkyDUX5uM
>
> This encourages early checkin of API changes and (so everyone can  
> get on board) and
> extensive private testing of features changes because nobody wants  
> to be the one called out during
> the push.  The problem with the "unstable" branch is that it is just  
> that "unstable" and when something
> is unstable for long it both tends to remain that way and the  
> "blame" becomes muddled which
> dilutes peer pressure.  A 6-month cycle means you get small features  
> and API changes in quickly
> and large features are tested by stakeholders privately on tracking  
> branches and checked in
> en-mass when they feel confident they are stable (typically at the  
> start of the 6-month cycle so that they can
> use the early adopters as beta testers).
>
> Just an alternative to consider.

Indeed.  I would have to say that the httpd versioning scheme
has failed miserably because each time we opened trunk to a new
round of unstable it immediately received a huge, half-baked
commit of unstable code.  We should have placed major new features
in a needs-review branch until they had group support, which
would have allowed us to keep trunk in releasable form.

However, I do strongly recommend writing down a set of release
and versioning guidelines so that module/plug-in developers can
know when API changes are allowed and when compatibility is
ensured, since that also helps project developers resolve some
technical issues about what can be changed and when.  I think
that is what Paul was suggesting.

....Roy

Re: releases, branching, etc

[John Plevyak <jp...@acm.org>]

This leapfrog process has a lot of theoretical draw, and it is the one 
that Linux tried
but because the experimental line became a dumping ground for unstable 
code and
more code built upon it, the time between "stable" releases became so 
long that all
the major stakeholders ended up doing significant backporting. I don't 
think it can be
considered a success.  If someone knows a project which has used this 
model successfully
(for several years) I would be interested in knowing about it. 

Alternatively, there is the 6 month stable model.  In particular there 
the OpenBSD variant
which has a window for feature lock and a short all-hands release press:

http://www.youtube.com/watch?v=i7pkyDUX5uM

This encourages early checkin of API changes and (so everyone can get on 
board) and
extensive private testing of features changes because nobody wants to be 
the one called out during
the push.  The problem with the "unstable" branch is that it is just 
that "unstable" and when something
is unstable for long it both tends to remain that way and the "blame" 
becomes muddled which
dilutes peer pressure.  A 6-month cycle means you get small features and 
API changes in quickly
and large features are tested by stakeholders privately on tracking 
branches and checked in
en-mass when they feel confident they are stable (typically at the start 
of the 6-month cycle so that they can
use the early adopters as beta testers).

Just an alternative to consider.

john




Paul Querna wrote:
> This stems out of a discussion we had at ApacheCon about how best to
> do releases and create stability for Traffic Server.
>
> httpd's VERSIONING:
> <https://svn.apache.org/repos/asf/httpd/httpd/trunk/VERSIONING>
> This document explains how httpd is trying to balance maintaining a
> stable version used by millions, and at the same time introduce new
> features quickly.  I believe TS would benefit from adopting a similar
> philosophy on stability of APIs.
>
> httpd's release Q&A:
> <http://httpd.apache.org/dev/release.html>
> This document covers in Q&A style various bits of info on how HTTPD's
> releases are done.
>
> The tools httpd uses to make a release are here:
> <https://svn.apache.org/repos/asf/httpd/site/trunk/dist/tools/release.sh>
>
> It would also be good to get TS building in CI, if someone has time
> you should mail infrastructure@ and work to get it all setup:
> <http://ci.apache.org/>
>
> Any questions I can answer?
>
> -Paul
>