[development] RFC: drupal as a moving target

[Daniel F. Kudwien]

> That doesn't mean core have to stop to be revolutionary on 
> some aspect but that new needs should be taken into account 
> when deciding what to change, how fast and how.
> 
...
> If you change 3 different parts of the API in one round, 
> porting modules will be a harder task than if you concentrate 
> on making one part of the API really really nice so that it 
> won't have to be touched soon. Changes will still be radical 
> in terms of improvement but porting may become an easier task.

Please correct me if I understood you wrong, but I think you're arguing for
backwards compatibility in Drupal's APIs.  This has been discussed several
times before and the arguments are still valid:  Ensuring backwards
compatibility would lead to unnecessary overhead in the source code and
longer development cycles.

For example, the new menu system in D6 forced module developers to re-write
most of the code in hook_menu().  While I think that providing backwards
compatibility basically would have been possible, the API is much cleaner
without it.  Upgrading a module to the new API is (for most modules) fairly
easy, since all aspects are well documented.

However - to continue this example - modules that were doing crazy things
with an "old" API (like Drupal Administration Menu) have a hard time porting
to D6.  While backwards compatibility certainly would not help them in any
way, I can clearly see a need for communicating major API changes in Drupal
core to potentially affected (suffering?) module (maintainers) in contrib.

For instance, the new database API currently in progress for D7 will break
each and every module in the wild.  That's good, since the new API will
introduce great features and better compatibility with other databases.
However, there might be modules in contrib that need support for advanced
functionality (f.e. multilingual solutions, integration and migration
modules) which should be taken into consideration while developing the new
API.

Daniel