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