Update 02-drush-versions.md "Available Drush Versions"
Drupal 11 says it is available, but not really. We only support this version, Drush 11 has to be installed as a site-local Drush
Closes #
Summary
Doc Page Title - <Enter a one sentence summation of the pertinent changes (including not-yet-completed work) provided by this PR.>
Effect
The following changes are already committed:
Remaining Work and Prerequisites
The following changes still need to be completed:
- [ ] List any outstanding work here
Dependencies and Timing
- [ ] Other prerequisites that must be completed before merging this PR
Release:
- [ ] When ready
- [ ] After date: $DATE
Post Launch
Do not remove - To be completed by the docs team upon merge:
- [ ] Redirect
/old-path/=>/new-path/(if applicable) - [ ] Include/exclude pages ^ respectively within docs search service provider (if applicable)
- [ ] For Heroes - add a props post to the discussion board.
- [ ] Remove from the project board
Thanks for the PR @jrannelv!
I think we can remove content around managing Drush versions via pantheon.yml since newly created Drupal 9 and 10 sites default to site-local Drush 11 and 12 respectively. Newly created Drupal 7 and 8 sites default to Drush 8 (set via pantheon.yml but I expect we wouldn't recommend changing that given the compatibility table in this doc says that's the only supported version for D7-8).
Is there a non-deprecated use case for managing Drush via pantheon.yml?
related to #8793
What do you think? cc @stevector
@greg-1-anderson can you review and weigh in on the question I asked in my comment above?
Is there a non-deprecated use case for managing Drush via pantheon.yml?
Assigning to myself. I'm asking for SME assistance in slack
I think only Drush 8 works with Drupal 7, right? in which case there's no good reason for D7 sites to change their drush version via pantheon.yml. I feel D8 is sufficiently EOL that IMO we should avoid documenting "supported" configurations for D8 because D8 falls pretty squarely in the "possible but not 'supported'" category.
So I agree with @rachelwhitton that there's no good reason to mention choosing the drush version via pantheon.yml at all. The dichotomy between site-local vs pantheon.yml causes a lot of confusion for customers around the term "supported"..
IMO we should just document that drush version is configured via composer.json and link out to drush's own documentation about which versions are still supported by the community as the point of reference for what is "supported".
I started #9010 as a larger overhaul. @namespacebrian can I get your thoughts there on how I handled site-local vs. global? As long as pantheon.yml does indeed change Drush versions, I think we need to acknowledge it. If Terminus directly invoked the drush in vendor when it was there then I'd be fine downplaying the global drush more.