Could Drupal core move to a release often cycle?

Friday afternoon a fascinating conversation broke out at the SandCamp (San Diego) coder lounge about how to get more people contributing to core (and reviewing issues).

One of the issues mentioned is how people can't use the development version of core to build sites on and later have to deal with all the new changes to core when the next version comes out.

If there was a way to get people using drupal 8 now, for production sites, that'd help in various ways:

• By the time the official 8.0 release comes out, tons of sites will already be on it
• More testing of bugs with the new features (and help with the new features)
• People get the features they need sooner
• etc...

So, is there a way for drupal 8 to have that happen?

Problems with people using drupal 8 now:

• No head-to-head upgrade path
• More chance for bugs with new features
• Lack of contrib module support

So, how to get around those issues?

My proposal

• Tags and guaranteed upgrade path between tags. Tag every month or two, after many bugs fixed or major new features added. Since major features are now be developing in their own forks, they can get testing they need there. At work, we develop all major features in feature branches, and thoroughly test them there before they ever hit master. This has helped us a lot to iron out a feature while keeping master relatively stable. Then before a release, we test again a bit. So, if drupal did this module, it could tag whenever it thought a good point, and people could then be using those tagged version for production sites already. This will of course increase development and testing a bit, but the advantage seems immense.
• Make sure coder upgrade is updated as patches land to best of ability
• Automated coder upgrades of modules. We got jenkins, we got git -- could we combine those two so contrib modules could have an automated d8 branch of a module, perhaps corresponding to the above tagged version? If anything manual needs to be done, create a readme file of TODOS and allow patches be applied to the automated module so module authors can update their module, but not loose the auto updated functionality.

This way, drupal could move to a module where people are on the latest (d8) release, and be using it, gaining new features, and encouraged to participate more because the ability to use the get the new features is much sooner than currently. It will increase development time -- but will it, with more developers able/encouraged to directly participate?