C. Michael Pilato wrote on Mon, Jun 17, 2013 at 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?
How about: at the end of the third trimester, the release branch is
created, a release candidate is cut, and the 1st trimester begins on
trunk?
I.e., make all of those simultaneous. Trunk will be in Tri1 mode while
the release branch is in soak, so we won't have the problem of needing
to pay attention to two active branches. That's also consistent with
doing alpha at the end of tri1 and beta at the end of tri2.
Received on 2013-06-17 17:37:01 CEST