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

osopolar’s picture

osopolar
Primary language German
Location 🇩🇪 GER 🌐
commented

+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).

hutch’s picture

hutch commented

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.

owen barton’s picture

owen barton commented
Status: Active » Closed (duplicate)

See #446736: Have drush update be told to ignore a module/theme -- simple solution

naught101’s picture

naught101 commented
Status: Closed (duplicate) » Active

Owen, only the last point is duplicate, the first three aren't.

owen barton’s picture

owen barton commented
Title: Module version management » Upgrade control over version selection (dev to/from stable and allow minor upgrades only)

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).

Yorgg’s picture

Yorgg commented
Category: feature » support

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

naught101’s picture

naught101 commented

reverting

snorkers’s picture

snorkers commented
Category: support » feature

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!

lsrzj’s picture

lsrzj commented

Good I vote for this too!

Yorgg’s picture

Yorgg commented

Checking updates of disabled modules would be a great feauture.
I mean they must be disabled for a reason :)

ñull’s picture

ñull commented

+

davebv’s picture

davebv commented

+

moshe weitzman’s picture

moshe weitzman commented

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.

xjm’s picture

xjm
she/her
Primary language English
commented

Tracking (and +1, etc.).

monotaga’s picture

monotaga commented

subscribe

alexiswatson’s picture

alexiswatson commented
Component: Code » PM (dl, en, up ...)

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.

greg.1.anderson’s picture

greg.1.anderson commented
Status: Active » Postponed (maintainer needs more info)

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'.

alexiswatson’s picture

alexiswatson commented
Status: Postponed (maintainer needs more info) » Fixed

It appears to be so. :] I'll go ahead and mark this Fixed; feel free to reopen if necessary.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

greg.1.anderson’s picture

greg.1.anderson commented
Status: Closed (fixed) » Active

I am wondering if I put #17 on the wrong issue. Some of the requested features have been implemented (e.g. --lock), but we don't have #13 yet. Re-opening for future consideration.

greg.1.anderson’s picture

greg.1.anderson commented
Version: » 8.x-6.x-dev
Status: Active » Closed (won't fix)
Issue tags: +Needs migration

This issue was marked closed (won't fix) because Drush has moved to Github.

If this feature is still desired, you may copy it to our Github project. For best results, create a Pull Request that has been updated for the master branch. Post a link here to the PR, and please also change the status of this issue to closed (duplicate).

Please ask support questions on Drupal Answers.