Add support for *.drush-5.inc, etc., to allow module developers to provide different code for different versions of drush.

If we don't do this, then we need to add support for *.drush-5.inc for commandfile loading (and make sure that drush-5 and later ignores *.drush.inc if there is any similarly-named *.drush-INTEGER.inc available), pronto.

I prefer this road, than keep around legacy code from a prior version. Needs discussion.

Very glad to see this. As I was writing the new feature patch it dawned on me that this will be a big problem. I'm fine with the separate command files, but I could also see declaring api compatibility in the command hook (I know we've talked about that before), or even adding the 4 or 5 to the callback name.

Either way, we need to come up with something. I'm also in favor of doing this as opposed to trying to maintain compatibility in code.

I'll note that it is technically possible for module developers to do this today. Have a look at http://api.drush.org/api/function/_drush_add_commandfiles/5.x and focus on the $load_test_inc stuff. A module author can ship with two commandfiles and only load one of them by also shipping with two COMMANDFILE.drush.load.inc files with simple hook_drush_load() implementations (e.g. return DRUSH_VERSION == 5). I think Aegir uses this hook.

Apart from this strategy being obtuse, I don't think module developers will be too happy about shipping with two commandfiles. The commandfiles can share common code, but we might be causing too much aggravation. Not sure what other solution we can offer.

Declaring compatibility from within the command declaration is no good. We just can't load incompatible code. If we do, we'll run into duplicate function problems once the compatible commandfile tries to load.

Copying a valuable comment by by Greg.1.Anderson from #1175446: Best practice for upgrading shared drush to next major version that belongs here:

The largest issue we need to handle is Drupal modules that implement drush support. A Drupal module already needs to support multiple versions of core (ideally, anyway); it is a burden to also have to support drush 4 + drush 5 x Drupal 6 + Drupal 7. We should be very careful about breaking backwards compatibility for the command records and the most important APIs used by drush.

However, I agree that it should be possible to support multiple versions of drush on a system, and currently it is not. If the features module wants to use drush-5 functions, it forces anyone who wants to use drush + features to upgrade to drush-5; this in turn causes problems if the same user has other modules that are still on drush-4, if drush-5 breaks backwards compatibility for them.

To make this better, we'd need to do a couple of things.

First of all, we should modify commandfile searching so that paths are filtered out if they contain the pattern /drushNNN/, where NNN is any integer that does not equal the current drush major version number. This will allow users to make drush4 and drush5 folders inside of their .drush folder, etc.; this is better than putting in a drush major version in the command record, as it gives users the ability to organise their drush commands w/out modifying the commandfile (if the author has not correctly set up version checking in their commandfiles). This same facility should be used when searching for aliases and drushrc.php files (need to add searching for drushrc.php?), so that people can divide up their aliases and options by drush verison if necessary.

Additionally, it would also be a good idea if there was a commandfile "exception list", so a user could tell drush to ignore a certain module that was broken. For example, if module x did not work with drush 5, you could copy its x.drush.inc file to $HOME/.drush/drush5/x.drush.inc, fix it there (submit a patch to the issue queue for module x), and then add x to the blacklist in your drushrc.php file for drush-4.

Currenlty, %drush-script is ignored if remote-host is missing or localhost. It should be respected when present, even for local dispatches.

We should indeed implement these sorts of forward-thinking features and backport them to drush-4, so people will have a good management strategy for moving up from drush-4 to drush-5. I still think that we need to be cautious about breaking backwards compatibility due to the large number of interdependencies and permutations between different modules and different versions of Drupal core.

Has anyone done a survey of what can break in a drush-3 to drush-4 upgrade? I tend to think these versions are fairly similar, but it would probably be a good idea to maintain a document (in drush topic, perhaps) that enumerated the API changes and main 'gotchas' for each major drush version upgrade. A bit of a pain to maintain, but in theory, once drush-MAJOR.0 is released, the list from MAJOR-1 to MAJOR incompatibilities should never change. I'll see what I can do about writing something up for the drush-3 to 4 transition; me and my friend "grep" are going to do some research. :)

Subscribe.

I think the plan outlined in #5 is solid. Anyone have further thoughts on this. Anyone willing to take it on? This issue is marked critical for good reason.

Seems like the attached patch the first paragraph of the spec in #5. Just adds some drush4, drush5, etc to the $nomask for drush_scan_directory().

When we unify aliasfile searching with commandfile searching, this should apply to aliasfiles as well.

Nice work!

Attached is same patch plus unit tests for version specific config files and commandfiles. The commandfile one is not ready yet. I'll keep hacking on it, unless someone feels inspired to work on it today.

@Greg - not sure how I should proceed. Is my patch in #16 the latest for drush5? I'm guessing that you didn't try to fix the commandfile test, did you?

FYI, each UnitTest test should be executed in isolation. See 'runTestsInSeparateProcesses' in the doxygen in Drush_UnitTestCase.

I will look into the test fail on drush5. i'm not immediately sure whats different about commandfile loading between the two versions.

I fixed up the commandfile test and committed #16 to master. I think my commandfile test changes should be backportable to drush4.

Assigning to Greg for backport. See commit 54d1ca9aeeef91da9049f1b379aaa268fa814def

Oops. Also needs my next commit which is only 1 line: 5e7573d

Update: changed again in 539283b

Committed to drush4 without commandfile test since that uses a UnitTest which is not available on drush4.

Needs change notification

Change notice at http://drupal.org/node/1406996