Jump to:

The need to test against drupal 8 is increasingly urgent as it diverges from drupal 7. We can't stay in sync with a highly changing branch but it would be nice to at least be able to test and see how compatible we are and support the basics.

Looks like a good idea. There are a couple tests that deliberately test on a particular version of Drupal. I guess we'd want to skip those when they differ from the passed in MAJOR_VERSION.

In general, Drupal 8 is going to be really hard to support along with prior versions given the amount of replumbing that is going on with Symfony. We *might* need to move to a drush per drupal major version.

On a semi-related note, there has been some talk of rewriting Drush commands and Drush contexts using php objects. Generally speaking, it would be difficult to have a commandfile written for Drush-5 co-exist in this new environment. Maybe what we need is a version of Drush that is (a) specifically for Drupal-8 and (b) implemented with objects. For backwards compatibility, it could call Drush-5 via backend-invoke e.g. whenever the selected site was < D8. Then you could have a one-commandline UX without trying to support vastly disparate environments on one codebase.

I think Symfony stuff in D8 is going to drastically change bootstrap, to the point where it will be hard to be backwards compatible in Drush6. Your idea about backend_invoke is a bit crazy, but attractive :).

In the 'backend-invoke to drush5' scenario, do you think we can cleanly handle commands that do partial bootstrap? We don't even know Drupal version when we are dispatching to the command. I'm thinking of site-install, sql-sync, etc.

Just committed this to master and 7.x-5.x. This is a terrific improvement for keeping our Drupal functionality working reliably. Lets now run tests on 8.x and get everything working. Leaving this open.

As for our prior discussion, it looks like we are going to be able to ship drush6 with support for d8,7,6 so no need for crazy --backend stuff.