Maintain support for D8 in drush 8

[AdamPS]

Currently the install docs state

• Drush 9 cannot run commandfiles from Drush 8 and below (e.g. example.drush.inc).
• Drush 8 supports <= D8.3

This combination is a substantial problem for many site-owners and module developers. Hundreds of contrib modules have drush commands and some are not actively maintained.

Therefore it seems a high priority to enable drush 8 to support D8.4+.

As I understand it, the main difficulty is dependency compatibility problems. In particular it is likely to be infeasible to continue support of a global drush - and it seems reasonable to drop that scenario and require a site-local drush.

[greg-1-anderson]

Drush 8 status for Drupal 8.4.x is "happens to work" for the global install of Drush, and we are about to get the site-local Drush 8 working as well (8.x-dev already working -- we just need a stable release).

We don't have a lot of control over what happens with Drush 8 support vis-a-vis Drupal 8.5.x, which makes it difficult to promise compatibility. One of the main reasons we did Drush 9 was for maintainability.

We understand the importance; it would be great if we could get some Drush 8 maintainers to work on this, support pm-* and make, etc.

[AdamPS]

Thanks for the reply. Certainly "happens to work" is a lot better than nothing, but it is not entirely reassuring. Please can you clarify what is preventing a firmer commitment? Can you explain why drush 9 works better?

I don't think anyone is expecting any magic ability to predict the future. If some future version of Drupal makes a change that breaks drush support then sure at that point it becomes unsupported. However it seems rather pessimistic to state that it's not supported now because someone might break it in future.

What tasks are you looking for drush 8 maintainers to help with? I did try to get involved with fixing some of the open pm issues, but was told that pm was no longer supported and my PRs were rejected:-)

[greg-1-anderson]

The technique from #2787 is already implemented in Drush 9. Also, the code in Drush 9 is more modular and easier to maintain.

[weitzman]

In particular it is likely to be infeasible to continue support of a global drush - and it seems reasonable to drop that scenario and require a site-local drush.

Right. And site-local to me implies using Composer. Your idea of using site-local without composer (i.e. a tarball) wont work.

Closing this issue as re-justifying our "happens to work" position is getting exhausting. You don't have to like our answer, but please accept it.