There are things that should be considered obsolete on the drupal handbook as the OOP policy and the security policy... and a "myth" that the community seems to be proud of: Drupal is a moving target and we aren't scared to break the API. Drupal is now a mature project and people start to rely on it for projects that have a longer life span than the release process of Drupal. Still there are parts of Drupal that aren't still mature enough to provide a "stable" API and freezing them there would hurt the project. I did a rough estimate (sed -e '/5\.[xX]/' | wc) on http://ftp.drupal.org/files/projects/ this doesn't take into account multiple versions, features that moved to core, etc... But the result is indicative: D5: 372 D6: 76 I did read: http://drupal.org/handbook/version-info and http://drupal.org/node/65922 In the face of the current status of Drupal project and on the above data isn't it the time to adjust the above policy a bit? I think that many core dev grew up with Drupal and now have to babysit projects based on Drupal that have a longer lifespan than a Drupal release cycle, so it shouldn't be a problem to actually reflect this in a public policy that will help others to make their plans too. Weren't we saying that Drupal value resides in being a framework rather than a finished product? What is the value of a moving framework for devs? What about the development process and focusing on improving the aspects that will contribute in offering a mature *stable* API... or does this sound as a blasphemy? I saw that the later document got an important revision (August 2007) when life-cycle moved from 6-12 months to 12-24. -- Ivan Sergio Borgonovo http://www.webthatworks.it