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