Jump to:
| Project: | Drush |
| Version: | All-versions-5.x-dev |
| Component: | PM (dl, en, up ...) |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | postponed (maintainer needs more info) |
Issue Summary
It would be good to be able to have finer control over the upgrade command in drush.
Specifically, it would be good if:
* drush update would NOT upgrade from stable to dev versions.
* drush update would NOT upgrade major versions (ie. first number of module version, e.g. Panels 3.x)
* drush update could be explicitly called with a switch to upgrade to the newest major or dev version (--major or --dev).
* modules could be "pinned" to the current version - ie. drush update ignores them completely. (this might require some kind of registry?)
The last one would be especially useful, because it would allow the user to be sure that their customised modules wouldn't be overwritten during a general update.
The first two are a safety issue, I guess, because newer versions of modules are sometime incompatible with previous versions' settings (like the WYSIWYG 1.x -> 2.x upgrade)
Comments
#1
+subscribing.
... especially to Point 3. Sometimes I use dev versions because they offer features and fixes which the stable version don't have. If I run drush to update, it want to override a dev version with an older stable version. I'd like to keep/udate dev versions until there is a newer stable one. It would be nice to show the release dates of the module versions in the update overview (maybe with an additional option --show-dates).
#2
Does drush ignore modules which have had the 'added by drupal' stuff removed from the .info file?
That would be a good way to protect custom versions.
#3
See #446736: Have drush update be told to ignore a module/theme -- simple solution
#4
Owen, only the last point is duplicate, the first three aren't.
#5
Fair point, updating the title to match.
I think this would probably best wait until after http://drupal.org/node/112692#comment-1471298 - looping through the update array is annoying (and hard to make consistent with subtle update module changes).
#6
Hi,
Some modules are updating to the dev version and some are updating to the latest release.
Isn't it possible to fetch the latest release and still use cvs or svn as a package manager?
Examples:
Geo HEAD 6.x-1.x-dev Installed version not supported
GeoNames 6.x-2.x-dev 6.x-2.x-dev Installed version not supported
Regards,
Jorge
#7
reverting
#8
Point 3 - control over DEV or formal release would be a really useful feature, especially as some modules default to formal releases during drush update commands, killing off any DEV modules. Also having more control over the dl download commands for either a specific version, or at least a DEV release would be fantastic.
Gets my vote!
#9
Good I vote for this too!
#10
Checking updates of disabled modules would be a great feauture.
I mean they must be disabled for a reason :)
#11
+
#12
+
#13
I think we should support a new option which is an array configured in drushrc.php thats recognized by updatecode. This array would have a project as key and one of several magic options as value. those options might be 'pin', 'no-dev', etc. Food for thought. I'm considering a similar array in the new core-upgrade command where admin can choose the version used in the target site.
#14
Tracking (and +1, etc.).
#15
subscribe
#16
A big +1 to this feature, and I could see myself agreeing with moshe's proposed solution. In fact, I don't think there's a single use case above that I don't encounter, so I'd be very happy to test patches and the like.
#17
There have been a lot of improvements in these areas recently. Test against HEAD and see if it works now; I suspect this can be closed as 'fixed'.