To be more clear, here's what I think is broken in the current release planning:
1. The dates are wildly unpredictable 2. People aren't allowed to work against trunk on features for multiple iterations (see #1072) 3. Stable branches diverge too much, causing duplicated effort. (we essentially implemented #1072 twice for 0.6 and 0.7) 4, back porting features is risky and causes bugs, esp with the limited QA available -ryan On Thu, Jan 13, 2011 at 2:32 PM, Ryan King <r...@twitter.com> wrote: > I think many believe that shipping 0.7 took longer than it should. > Rather than going into why that happened, I'd like to propose a better > way to move forward that will hopefully allow us to ship on a more > predictable schedule. This proposal is heavily influenced by the > google chrome release process: > > http://www.scribd.com/doc/46659928/Chrome-Release-Cycle-12-16-2010' > > ..which is heavily influenced by how large websites deploy code > (everyone close to trunk, hide incomplete changes behind configuration > flags, etc.) > > I'm not saying we should adopt this process as-is, but some aspects of > it seem like they would be valuable– > > # Fixed schedule > > We should set a fixed schedule and stick to it. Anything features not > ready at branch time won't make it and will be disabled in the stable > branch. > > # Trunk-first > > 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. > > We should be more liberal about committing things to trunk early and > iterating on them there (rather than iterating on them in patches). If > the features are unstable we can either hide them behind configuration > flags or remove them when we cut a stable branch. > > # Automate all tests > > I think the only way that we can keep people close to trunk and stay > stable is to build automated tests for *everything*. All code should > be exercised by thorough unit tests and distributed black-box tests. > Every regression should get a test. > > > Chrome has a 6 week cycle. I think ours would be more like 4 months > for major releases. > > Whatever we do, I think the schedule needs to be more predictable, > which means that the contents of each release will be less predictable > (since its "whatever's ready at the appointed time"). Like the Chrome > presentation mentioned the idea isn't raw speed, but predictable > release schedules. > > Feedback please. > > -ryan >
