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.
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".
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Received on 2013-06-17 15:37:24 CEST