Upgrading Drupal when modules are not updated
Forgive me if this is not the correct place for this post. I struggled with where to post this question.
I have been working with Drupal off an on now for a few months. Going back and forth between Wordpress and Drupal. I like features in both and I may eventually use both together if I can get them to synch up.
I prefer Drupal because it seems to have more features and more of what I am looking for. My concern is this:
Why do the modules have to be updated to match the core each time a new core is released. I am not real familiar with the code base, but I would think that if a module is built to have it's own tables, then most if not all modules should work with a new release. Even modules that may reference core tables as long as the release does not change table names and field names, but may add new columns as needed to support new features. I suspect that modules may be using queries with Select * which may be causing some problems. Can anyone shed some light on this?
I ask this because I would like to build a new site using the new core, but most of the popular modules are not ready for 6.x yet. So, I think I will implement a 5.7 solution with all required modules and upgrade later.
I just wanted to see what the issues were as to why the modules have to be updated for each core.
Thanks.
Scott

The API
The api (api.drupal.org) changes from major version to major version. Every modules calls code from core and core calls code from each module.
A module which does a
A module which does a completely isolated kind of job might be able to do all the work itself, but usually a module which manipulates information wants to use Drupal to also create, manage and display (theme) that information consistently.
So, modules use Drupal APIs as building blocks for most things. And the core APIs change a lot between major versions. Things are added, dropped or rearranged to keep the system logical and free of bloat.
free of bloat
I guess this is the biggest reason.
I suspect backward compatibility could be done, but with definite added bloat.
Would some bloat be acceptable for backward compatibility. With apis, as long as the interfaces do not change then the modules that use these apis should not be impacted.
Actually after this brief discussion and as I write I realize what the problem is...
We are limited by the technology. I have been working with .net and Pl/Sql for that last several years forgetting that php and asp do not support overloading. I think this is the real limitation to supporting backward compatibility with minimal bloat.
Thanks for the discussion.
here you go
http://drupal.org/node/65922
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain