On Fri, 2011-01-14 at 13:11 -0600, Eric Evans wrote: > > Everyone on chrome commits to trunk first. I think the important > > change we could make is to keep everyone closer to trunk. We spend a > > good deal of effort back-porting patches between major versions. I > > think we should make the major versions less different. This would > > mean letting them live for shorter amounts of time and possibly > > making them bugfix only. Currently we add new features in stable > > branches, but I think if we made the major release schedule more > > predictable people would be more comfortable with letting their new > > feature wait until the next major version. > > I'll call your keep-close-to-trunk, and raise you a: > > * branch as soon as all planned features land in trunk > * iteratively release betas w/ bug-fixes only > * release candidates are actual candidates for the final (not > releases) > > The time between creating the branch and making the release should be > as short as practical, and there should be no backward incompatible > changes between the first beta, and final release.
The discussion seems to be petering out and I wonder if that means folks are still trying to wrap their heads around everything, or if we have consensus. If we're in agreement on 4 months between releases, and feature-freezing branches in the run-up, then that would leave us with say 7 weeks (give or take) to land everything in trunk that we expect in the next release (and I would think that at this point we'd at least have a good idea what that'd be). -- Eric Evans eev...@rackspace.com
