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
