On Sun, 26 Feb 2006 05:56:24 -0600 Derek Wright wrote:
I'm still too new around here to have any profound insights on what to do about all this, so unfortunately I don't (yet) have a concrete suggestion to share.
this recently caught my eye: Backporting Forms API to 4.6. Experimental migration feature http://drupal.org/node/51390 i think this is just what we need: 4.6 contrib modules that provide a 4.7 compatibility API. of course, not every new feature of 4.7 can be emulated, but key API changes that modules *must* make (e.g. forms) which can still be implemented as contrib in 4.6, could solve a *lot* of problems with module maintainance and release policy. the native 4.6 versions of contrib modules should remain stable, only doing security updates, bug fixes, or very small, localized improvements to existing functionality. where possible, modules can port their 4.7 version to the required core API changes, with an eye towards staying within the bounds of whatever can be successfully emulated in the 4.6 compatibility contrib module. then, new functionality can be added to the development 4.7 version of the module, but sites that want to stay at 4.6 can still use it. if radical changes in 4.7 that can't be emulated are needed, *then* the module maintainer can worry about forking their code, instead of *always* having to fork as soon as a new major release of core comes out. maintainers could make a "DRUAPL-4-7_BACKPORT-4-6" branch for their module, and leaving whatever 4-7 goodness that still works in 4.6 compatibility mode in there, and move on with the bleeding edge 4.7 development in the DRUPAL-4-7 branch (or HEAD). better version numbers for contrib module releases would be a huge help for all of this, if not a requirement. the lack of "point releases", or "sub versions" or whatever you want to call them is a serious limitation imho. i don't know how easy it is for module authors to add new branches to be released to their drupal.org project page, but that'd be good, too. i fully understand why the core developers don't want to spend too much time doing legacy support inside core itself. but, if it's relatively easy to cover the main 4.7 core API changes (forms) via a 4.6 contrib module, that might solve 75% of the problems. perhaps a tiny fraction of the core development team's effort could be put into giving insight to the people trying to make these compatibility modules work, and in rare cases, changes in core itself could be done with an eye towards contrib compatibility (as opposed to trying to maintain core compatibility). maybe some of the enterprise folks could fund/support a compatibility layer development team (analogous to the security team). if we had regular compatibility modules for the most common required API changes, it'd be easier to request/enforce a more uniform release management policy from contrib authors, since the default choice is a good one (you still have to upgrade to a new core API, but there's a compatibility module you can use for the current stable version that will work for most of what you need to do, anyway) instead of forcing them to fork to even work with the next release at all. -derek