Download the deleted module's version on cleanup

I'm starting to work on it!

I would change this feature request to a sort of bug report as module misbehaves if you have not the latest version of a contrib!
My scenario is the following:
I've downloaded easy_breadcrumb 7.x-2.12 which is not the latest one. pm-download drush command wants to download purely the latest one which in this case will download 7.x-2.15 that could cause issues if there are hook_update_N() implementations or anything that breaks the safe deletion.
So the step-by-step reproduction is the following:
1. Get a d7 site installed and make easy_breadcrumb 7.x-2.12 installed on your site (drush dl easy_breadcrumb-7.x-2.12 then drush en easy_breadcrumb -y)
2. Remove the folder that has easy_breadcrumb to produce a module that this deleted_modules should realize.
3. Execute drush dmc command, output will be similar:

$ drush dmc
1 deleted projects found that were not properly uninstalled.                                                                                                  [warning]
 Name             Version   Status    Schema version 
 easy_breadcrumb  7.x-2.12  Disabled  -1
The modules listed above will be downloaded, enabled, disabled and uninstalled.
[WARNING] This action should only be done if you have previously backed up the environment.
Are you sure? (y/n): y
Project easy_breadcrumb (7.x-2.15) downloaded to /sites/all/modules/easy_breadcrumb.                                            [success]
The following extensions will be enabled: easy_breadcrumb
Do you really want to continue? (y/n): y
easy_breadcrumb was enabled successfully.                                                                                                                     [ok]
easy_breadcrumb defines the following permissions: administer easy_breadcrumb
The following extensions will be disabled: easy_breadcrumb
Do you really want to continue? (y/n): y
easy_breadcrumb was disabled successfully.                                                                                                                    [ok]
The following modules will be uninstalled: easy_breadcrumb
Do you really want to continue? (y/n): y
easy_breadcrumb was successfully uninstalled.                                                                                                                 [ok]
Module easy_breadcrumb was properly uninstalled and should be now safe to remove from the file system.                                                        [success]

In order to get the proper version that has been installed on the site, we should have downloaded the 7.x-2.12 which didn't happen 'cause pm-download gets the latest available version. My initial patch attached now resolves this.

Regarding updb command if the deleted_modules only downloads the real version that has been in use on the site, I see no reason to execute updb at that stage, especially because it could trigger other hook_update_N() implementations that should not be touched by this module.
There is a way if we want to implement by any reason an update call which is way so manual and in the case of above scenario when 7001 has been added to the codebase after 7.x-2.12 (came by 2.13 release in this commit: https://cgit.drupalcode.org/easy_breadcrumb/commit/easy_breadcrumb.insta...)

include_once DRUPAL_ROOT . "/includes/update.inc";
$c["results"]["#abort"] = array();
update_do_one("easy_breadcrumb", 7001, array(), $c); 

I would say if there was no version provided by the system, as a fallback it seems more reasonable to execute updb before disabling the questioned module (when it basically gets enabled) then just before uninstalling it. But I'm not fully sure we need to do that :/

Yes, actually it works pretty well with dev versions too. The only issue that I see with a similar approach (but it's more of a policy question), how patches if any has been used on a deleted module could come back. Sometimes I see weird version numbers that are generated because of hashes of commits and those versions can't be used by pm-download, so maybe a validation on this version with regexp could be useful.

About your second comment, I'm quite sure we shouldn't address db updates by this module as it might cause other issues. The way that I've suggested above to call manually https://api.drupal.org/api/drupal/includes%21update.inc/function/update_... could be implemented, but personally I see it as a very rare edge case, definitely calling it non-release blocker thing - it might be a nice new added feature after first stable release.

I'm gonna come back to you later today to address the validation on version numbers, so let me assign the issue back to me.

As we don't have the real files, I'm afraid we can't even make a diff between the version from d.org and the indicated one if it's not a real release :(
I'll be back with this validation today and we are good to go with this issue :)

Hey @Manuel,
not yet, I had a quite busy period and just landed in Fuerteventura to start my Christmas vacation ;) If you want, go ahead with committing it, but in the coming days I'm planning to make progress on all the issues that I haven't had the time for.
Bests,
Balazs.

Hey @Manuel,
I've done now the check for the versions and these are the accepted ones:
7.x-1.0
7.x-2.12
7.x-10.02
7.x-dev
and these are not acceptable:
(no version is provided, usually when the module is directly git cloned with its default branch)
7.x-1.x
7.x-1.0-dev
7.x-1.0-weirdcommithash
I've tested it with easy_breadcrumb again with many different scenarios and it seems works well.

Sorry to not give an interdiff now, but as the previous patch was only 2 lines of change, that I've improved a bit, also with this new if statement with the preg_match, the interdiff would show basically the whole new patch, that makes not much of a sense :)

I think in this case we could go with a different approach as we also mentioned in briefly above: asking approval to get the latest version (in case of easy_breadcrumb 7.x-2.15) as a sort of 'fallback option' which is currently not supported by the execution if there is no identified version. The problem might be the different major versions! In case of easy_breadcrumb it doesn't exist, but there are modules (first come to my mind: media!) where downloading the latest major might cause other issues if the one before has been used.
So the plan is:
if there is no version provided, ask the user's approval to get the latest one regardless of its major version, but highlight it can cause issues, so ask for back-up and blabla :)
Then if s/he agrees, do that with the latest version. I need to check deeper how pm-download works, can get give extra parameters to it to just give back the latest release tag before it wants to really do its work. Maybe a different drush call has to happen, dunno atm.
Btw do we consider this as a release blocker or a further improvement? Currently, I feel it's safer to just do not do anything, instead of guessing and possibly causing issues. What're your thoughts?

But yeah, overall we can give the following messages:
"No version of {$name} is found, unable to proceed."
OR if there is a recognized version:
"Installed version '{$version}' of {$name} is not supported, unable to proceed."

Totally agree ++
Here is the patch that addresses this improvement to give different output when the version is known or is not.
Also made a small typo improvement to use full sentences everywhere :)
Let's test is then we are good to go!

Good point, here is the improved patch with commenting the preg_match.