On 8/11/07, jordan@theoverclocked.com <jordan@theoverclocked.com> wrote: <snip call for freezing the API over multiple releases> The original problem you state "trying to get developers to update their module for the latest Drupal release gets old fast" is a real problem, but there are multiple ways to solve it without requiring Drupal core API to be held back by a need to maintain compatibility with previous releases. As others have pointed out and hinted towards, there are a couple options: 1. If you want to see it, you can write your own contributed "legacy" module that would provide the necessary wrappers for modules. This seems like a losing proposition to me. 2. The coder module provides assistance with upgrading a module. If you can help Doug Green make sure that the module works well, then that limits the amount of pain for contrib authors during upgrade. http://drupal.org/project/coder 3. For the modules that you'd like to see upgraded you could provide code, reviews, testing, documentation, or a bounty to motivate the module maintainer. For several of my modules if someone just provided testing and documentation (which anyone can do) it would free me up to focus on the code. And of course if someone else provides the upgrade patch...that simplifies everything. 4. Just embrace the "Drop is always moving" philosophy and move on. I wrote about this and other occasionally surprising Drupal philosophies in a welcome guide for "seasoned professionals" http://pingv.com/blog/greg/200706/drupal-seasoned-professionals-quick-guide-... and you can find the original documentation on this particular social norm at http://drupal.org/node/65922 I appreciate the time you've taken to identify a problem and propose one solution, but I think any time working towards a backwards compatible API would itself be wasted work. Greg -- Greg Knaddison Denver, CO | http://knaddison.com World Spanish Tour | http://wanderlusting.org/user/greg