[development] enterprise needs

[Derek Wright]

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