Below I put some snapshots from Googl’e chrome release cycle presentation with some comments.

They originally planned this :

And got a lot of troubles with this cycle like :

• Long lived branches, which : Made supporting the branch (i.e. merging changes) more difficult as we drifted further from the trunk…
• Unpredictable release cycles, with date targets we could never hit, and….
• Engineers who were always in a rush to get their features into “this” release since we couldn’t make any promises about the schedule
  so they slightly change ( and simplify ) it to this 3 channel diagrams by making release shorter ( and reduce scope )

So they change traditional scheme to this one :

And then make it work in real life by cutting scope at release ( by disable features ) : Establish clear expectations (and engineering practice) to developers that any features not ready to ship at branch will be disabled (i.e. we only cut post branch, never add).

So it works fine for google guys and their rules are :

• The branch point is the end of our development cycle
• Features only get disabled post branch point
• Features should be engineered so that they can be disabled easily (1 patch)
• Only stability, security, and critical regressions can ever block a release

For me it’s looks fine for in-house development, but for me it’s big question how to apply same scheme for outsource development.

• The Future Is Big Data in the Cloud
• NoSQL – the new wave against RDBMS