Forwardport doctrine - a proposed solution for Drupal major version migration problem

Why, what for?

As can be seen from the active discussion in Predictions for 2013, there is a huge demand for painless major version migration.

What's the problem?

The problem is that the major versions of Drupal are incompatible with each other (there is no backward-compatibility). This is good in the sense that each new major version of Drupal doesn't have a compatibility burden, and therefore represents the best possible functionality. But it is bad, because it makes difficult to migrate from earlier versions, and therefore prevents the spread of a new major version.

What is proposed?

• For each Drupal module and the core make a common part of the major releases as a single major-independent library, and turn major-dependent releases of modules into adapters to this common part.
• The basis of the common part is the latest major version of the module. Thus, the release of the latest major version will address to the common part without any adapter at all.
• Each adapter of the n-th major version depends on the adapter of the n +1- th release version. Thus, the older major version of a single site, the greater number of adapters to the common part it needs for each module and the core.

What are the expected results?

• + Each adapter = upgrade path: this is true because to make all tests for older major version passed, you must edit the adapter, that is, to teach an old major version to understand the new structure. How else to make it work, but to write a complete migration path? In addition, a major version migration process is nothing more than the installation of more advanced adapters, first for the core, and then for each of installed contributed modules - and then uninstallation of the old adapters. This process is reversible until the disabled adapters are not removed entirely - just disable the new adapter and turn on old ones back as they were.
  Thus, by simplifying the process of major version migration, we dramatically increase the user base of the latest major version, which in turn increases the speed of development, testing and implementation of new functionality.
• + There is no need to port patches thanks to maximizing code reuse: every bug fixed in the common parts, automatically disappears IN ALL major versions, regardless of how many adapters are used to reach this common part through.
  This reduces the maintainership burden, which has a positive effect on the speed of development too.
• + It increases the interest of ordinary users to upgrade to the latest major version: because it is a sure way to speed up your site by disabling adapters of the previous major version.
  Thus, the most advanced, bleeding-edge functionality developed, tested and implemented faster again thanks to an increase of the user base.
• - Additional dependency: minus is that there is an additional dependency. Each module that wants to use the Forwardport doctrine, is forced to become dependent on Libraries. I assume this is a price worth paying for the benefits that this doctrine promises.
• - The installation procedure differs a lot from the usual: to bring the module that embodies the Forwardport doctrine in working condition, the following steps are required:
  • Download major-dependent release of the module as usual (using drush dl or by unpacking downloaded distribution manually into sites/all/modules)
  • Due to the dependence of the Libraries, download and install the Libraries
  • Using Libraries download and install a common major-independent part of the module, which is plugged as a library, because it is not major-version dependent.
  • Install the module itself, since all the dependencies are satisfied.

  I guess this is not much of a problem, as many of the existing modules (some of which are very popular) are already working on this scheme: PHPMailer, Wysiwyg, Colorbox and so on.

So, what is the plan?

• First, we need a protective layer (ANTICORRUPTION LAYER in terms of domain-driven development): namely, a buffer that will implement this doctrine gradually without any sudden movements. That is, on the one hand, it works as a proof of concept, and the other - without disrupting the existing infrastructure. Evolution rather than revolution.
  I'm going to use Module Object Oriented Programming API, one of the modules I maintain, as such a fuse. It is useful (among other things) by the fact that it operates each module as a class - which dramatically simplifies development of adapters: simply apply Adapter design pattern. The task is more facilitated by the fact that we have the decorator pattern already implemented in Moopapi: it is not difficult to expand it to the adapter.
• It is necessary to allocate a certain module as a pilot project: extract its major-independent part and turn it into a library (that is, to make it available to all major-dependent release of this module).
  I'm going to use Botcha as such a pilot project. First, because it is once again one of the modules I maintain - that is, I have full access to its source code. And secondly, because I've already done all the necessary preparatory work - and here's the results: in the attachment you can find the diff-file, which contains all the differencies between major releases of Botcha. In my opinion it looks optimistic and perspectively: it would not take much time to abstract these differences, putting them to the major-dependent adapters, and to turn a common part into the library. In the first iteration, I believe, we can deal without the adapter classes as such. For the demonstration of concept it is enough simply to put the SWITCHes by VERSION in the right places - then all of the code will go into the common part, and the major-dependent releases will be just a simple implementation of Libraries-hook. This design provides a good basis for further refactoring.

Why Forwardport?

Name emphasizes its opposite to doctrine of backporting: instead porting changes from new major version to old one, we take the most recent code as a foundation for all major releases - and teach adapters to work with it in the old way. Thus, we maintain a strength of Drupal (no compatibility burden) - but at the same time gain new positive quality: a painless major migration.

Questions? Suggestions? Wishes?

Any feedback is welcome. I want to receive the comments from experienced Drupal-developers to evaluate how promising my idea before I start actively implement it.
Thank you for reading! Please post a comment.