[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Proposal for reducing Subversion's lengthy (and unpredictable) release cycles.

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Mon, 17 Jun 2013 11:24:45 -0400

On 06/17/2013 09:57 AM, Daniel Shahaf wrote:
> On Mon, Jun 17, 2013 at 09:36:29AM -0400, C. Michael Pilato wrote:
>> On 06/13/2013 10:30 PM, Greg Stein wrote:
>>> Fair enough. But I think you're talking about Step Two. There is more
>>> work on what "stable" means, what time schedules to use, etc. That's
>>> Step One.
>> In private mail, you also asked for tighter definition of the various
>> trimesters of stability (which is an interesting choice of terminology in my
>> own personal life right now, but I digress...). Here's my thinking:
>> Tri 1: Trunk builds and passes tests, but may have crazy new,
>> sweeping-change types of features on it. We've tried to be
>> forward-thinking, but who knows if these are the APIs/protocols/etc. that
>> we'll wind up with in the release. At the end of this period, we might say
>> we're merely "build stable". We could ship an alpha at the end of this
>> period to get the crazy new features into the public's hands for user
>> acceptance testing.
> I like the idea of sprinkling alpha/beta releases along the way.
>> Tri 2: Trunk builds and passes tests, and the crazy stuff is still getting
>> hammered into release-worthiness, but we're not allowing any more crazy
>> stuff in. Smallish features and enhancements are fine, but nothing like a
>> WC-NG or Ev2 or FS-NG or.... At the end of this period, we would say we're
>> "feature stable", and could ship a beta release.
>> Tri 3: Trunk is feature-complete. Oh, and it builds and passes tests. :-)
>> We're serious about getting this thing ready to release, now. Strictly
>> speaking, this "period" of trunk's life extends until the final release is
>> cut by taking the "release branch" side of the fork in the road. But we
>> don't want to lock down the trunk indefinitely, so we get as much
>> stabilization done on the trunk as we can before branching for release
>> stabilization and reopening the trunk for a new "first trimester".
> Which trimester is concurrent to the "1.N.x branched, but 1.N.0 not released
> yet" period?

That was a point we didn't fully settle on in Berlin. Today that period is
a limbo of sorts. Trunk is technically open to anything, but we don't like
to codebomb it because it complicates backports of stabilization fixes to
the release branch.

I suggest that it should instead be the first trimester of the new release
cycle -- and as such, wide open to changes -- because if all goes as
planned, there will be fewer things to backport anyway (since we will have
already been sitting in a feature-frozen stabilization mode on the trunk for
three months prior.)

Other ideas?

C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development

Received on 2013-06-17 17:25:19 CEST

This is an archived mail posted to the Subversion Dev mailing list.