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 <cmpil...@collab.net> CollabNet <> www.collab.net <> Enterprise Cloud Development
signature.asc
Description: OpenPGP digital signature
