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
