The one change I think we might see this time, and which I'd support, is a much harder code freeze. We have the potential for SimpleTest coverage and an extended development cycle, leading to a two months instead of seven for code freeze this release - which will be a first if it happens. With a longer code thaw, there should be less of a rush to squeeze patches in during code freeze, and with SimpleTests we should know much quicker if stuff is broken (and stop it being broken at all), meaning less time spent bug hunting during the beta/RC period too. Core being pretty much stable for two months prior to official release means there'd be more incentive for contrib maintainers to port modules early, in the relatively safe knowledge that no big patches will land during that time frame.<br>
<br>The other main issue is CCK and Views are dependencies for a very large number of contrib modules, and they're under-going major rewrites - so there's a knock-on effect in terms of sheer numbers of modules being ported. While this makes raw numbers of contrib upgrades seem slower, as with 4.7.x - 5.x they're also going to render a lot of modules, and code within modules, obsolete. Every major Drupal release, despite there being more modules in total, there's also be a centralisation of code. 4.7-5.x saw the near disappearance of 'node type' providing modules, a lot of other areas are increasingly dependent on central APIs for heavy lifting as well (drag and drop in 6.x for one example) as opposed to maintaining their own systems. The issue isn't whether APIs break, it's whether we can continue to make a lot of modules (and code inside modules) unnecessary with those APIs - so the majority of contrib gets smaller, lighter and easy to upgrade. Of course one huge API change from D6 to 7/8 might be fields and/or views in core. I think that'll make the upgrade process quicker rather than slower for those releases, despite breaking a whole bunch of APIs in the process.<br>
<br>Now this might be the sort of thing you're thinking of when you talk about trying to move to a more mature, stable API, but otherwise I don't see how it's much different to <a href="http://drupal.org/node/132496">http://drupal.org/node/132496</a><br>
<br>