Proposal: the current core development cycle is releasing a stable (for example Drupal 5), opening up HEAD, hacking for N months and then releasing the next stable (Drupal 6) meanwhile 5.1, 5.2 etc gets released for bugfix. I propose that during the hacking period we do developer releases from time to time, maybe every two weeks, once there is something new that somewhat works. So there will be occassionally Drupal 6.x bugfix releases and more often Drupal 7.x unstable releases.
A few scenarios that might happen:
- Someone grabs a contrib module and try to update it. Currently it seems like a waste and impossible because HEAD is always changing. It still will be a waste somewhat because surely Drupal 8 (stable) and Drupal 7.3 (developer release) will be different API wise but not all effort is wasted and if some API does not work out for you, here is the chance to voice your concerns. The next "multistep node form" problem maybe won't need three releases to make easy...
- A consultant might want to do this because then she has a competitive edge -- honestly can tell her clients that she is already getting ready for Drupal 8. Currently noone can say that unless she is actually patching HEAD.
- A wise company might even set out a developer to port their custom modules because they have something to hold on. Again it's partially a wasted effort because API will change between 7.3 and 8 but, they might have a say in where the API will swing. A worthy investment.
- Once 7.3 is out, Dries can take a big patch and say, I commit this patch, and once HEAD is working again, I release 7.4. No other big patch gets in meanwhile. If said big patch is a big fluke, there is a point to easily roll back to. Other patches do not need to reroll daily, they can work with 7.3 constantly and when 7.4 is out, reroll then and only then.
Developer releases won't appear on the front page, nor on the download pages, only on http://drupal.org/node/3060/release. Garland page.tpl.php will contain a small header text, white on red saying "unstable release" so there is no mistake what it is.
So to sum up the advantages:
- Testable APIs
- Separated big changes
- Users might accidentally find it and think they should upgrade.
- We'll churn through major versions more quickly.