composer does not install latest version of module

That's an old version. You might check your requirements and see if it is pinned currently to that major version.

Use composer depends and composer prohibits to check your requirements. Depends on the old version, prohibits with the new version.

composer require drupal/migrate_upgrade:^3.0 should get you rc5

docker@cli:/var/www$ composer require drupal/migrate_upgrade:^3.0
    1/2:	http://packagist.org/p/provider-latest$313337caa2f091732c6153f8d06d06b6bdfac1a2c1e3ab7a168c4c609480c8c5.json
    2/2:	http://packagist.org/p/provider-2018-07$0d0198846df2374e6ab668ef7afbee66d0d9d825c6dc5aca0b5a390f72538748.json
    Finished: success: 2, skipped: 0, failure: 0, total: 2
./composer.json has been updated
> DrupalProject\composer\ScriptHandler::checkComposerVersion
Loading composer repositories with package information
Updating dependencies (including require-dev)
    1/1:	https://ftp.drupal.org/files/projects/migrate_upgrade-8.x-3.0-rc5.zip
    Finished: success: 1, skipped: 0, failure: 0, total: 1
Package operations: 2 installs, 0 updates, 0 removals
  - Installing drupal/migrate_plus (4.0.0): Loading from cache
  - Installing drupal/migrate_upgrade (3.0.0-rc5): Loading from cache
drupal/migrate_plus suggests installing sainsburys/guzzle-oauth2-plugin (3.0 required for the OAuth2 authentication plugin)
Writing lock file
Generating autoload files
> DrupalProject\composer\ScriptHandler::createRequiredFiles
docker@cli:/var/www$

I just got 8.x-3.0-rc5 using a tilde. Not sure what is better: using ~3.0 or ^3.0. Anyone?

composer require drupal/migrate_upgrade:~3.0

As there is no patch not need for 'needs review'.

There is no difference between ~ and ^ when dealing with the first release or zero version. However, generally speaking, using the carrot (^) is preferred. Seems like this might be resolved? If so, can we have someone mark this fixed or fix unable to reproduce.

The question is not answered yet!
Why is it not installing the latest?

As proven by require drupal/migrate_upgrade:^3.0 getting 3.0-rc5 there is nothing to stop at 2.0-beta1.

As mentioned following instructions, which need adjustment when desiring 3.0-rc5.

There is no difference between ~ and ^ when the constrain is x.y, there is for x.y.z. In ~x.y.z the x & y are fixed, ^x.y.z only x is fixed.

Ah, I think the reason is:

"prefer-stable": true

And when migrate_upgrade 2.0 was tagged, we didn't know there would be things in it that required a specific version of drupal. To make it work without a version, we need to get 3.x to a stable release.

Instead of just letting composer pick for you, try using composer require drupal/migrate_upgrade:^3. That seems to work for me without any issues.

I guess we make that somewhat clear on the project homepage, but I've made it even more clear now. If you would kindly mark as fixed, if this does in deed fix it for you?

Although prefer stable should have an effect, doubt it is the case here.

The project page mentions the dependency on Drupal Core but it is not reflected in the composer.json. Any reason why there is no composer.json tying the to appropriate core?

Consider it definitely wrong to resolve to 2.0 on a current core. Apart from that being an issue for Composer, consider it still an issue for this project. Suspect that is what Alex.a was trying to tell here.

Regarding issue status please read https://www.drupal.org/issue-queue/status ... there is nothing to review or RTBC. Thus active.

We have answered / found a workaround not about this project but about composer dependency management.

Better yet the project page refers to ^3 ... so fixed IMHO :)

Again, NO the issue is not fixed!

The composer.json are incorrect! They don't specify the proper requirements for drupal/core as mentioned on the project page. Resulting in the wrong version installed when not providing the version constraint, which is a workaround, NOT a fix of the problem. Providing a proper composer.json in both version with appropriate version constrains would be the only correct way to deal with it.

@heddn I don't think you can solve this. Not sure though. Maybe altering the 2.x and 1.x branch with core version restrictions

"require": {
    "drupal/core": "<8.3.0",
}

but that would be a 'from hindsight' solution marking old versions only being compatible with older Drupal. And it probably won't work as 2.0 is not requiring any core version.

I tried to find info on https://packagist.org/ but that does not know migrate_upgrade (obvious as we are talking Drupal packages).

composer info drupal/migrate_upgrade --all
name     : drupal/migrate_upgrade
descrip. : Drush support for direct upgrades from older Drupal versions.
keywords : 
versions : 3.x-dev, * 3.0.0-rc5, 3.0.0-rc4, 3.0.0-rc3, 3.0.0-rc2, 3.0.0-rc1, 3.0.0-beta1, 2.x-dev, 2.0.0, 2.0.0-rc1, 2.0.0-beta1, 1.x-dev, 1.0.0, dev-3.x, dev-2.x, dev-1.x
type     : drupal-module
license  : GNU General Public License v2.0 or later (GPL-2.0+) (OSI approved) https://spdx.org/licenses/GPL-2.0+.html#licenseText
source   : [git] https://git.drupal.org/project/migrate_upgrade 8.x-3.0-rc5
dist     : [zip] https://ftp.drupal.org/files/projects/migrate_upgrade-8.x-3.0-rc5.zip 8.x-3.0-rc5
names    : drupal/migrate_upgrade

support
source : http://cgit.drupalcode.org/migrate_upgrade

requires
drupal/core *
drupal/migrate_plus *

requires (dev)
drupal/coder ^8

It's quite lame we cannot pin branches to core version in a `back to the future` way.

re: #14
That is kinda my point in:

And when migrate_upgrade 2.0 was tagged, we didn't know there would be things in it that required a specific version of drupal. To make it work without a version, we need to get 3.x to a stable release.

But you put it more eloquently. There isn't any way to go retrospectively change a tag/version. So even if we tagged a new 2.1 that required a specific version constraint of Drupal core of release ~8.1, that wouldn't fix 2.0 release and composer would find it. So, the only "fix" for this is to 1) update docs or 2) release a stable 3.0.

I've opted for now to fix this with #1. I cannot control #2 entirely.

We're close to an 3.0 release, but #3009066: Error on Drush: An Option named "configure-only" already exists has me mildly worried. Before I cut a stable, I want to hear confirmation that 3.x HEAD is still working. There isn't as much automated testing of this project as I'd like, and that's made even harder with drush integration testing needed, so I have to rely on manual testing for a lot of things.

Also, in reguards to the issue status. Normally for issues that have patches, we wouldn't set something to needs review, rtbc, etc. But since this is a support request, I'm using those statuses for communicating if we're close to resolution of this support need. If we need to post-pone this support until we release a stable 3.0, so be it. I feel docs are more than sufficient, but meh. The community will speak.

If the latest RC I just released is not flagged as broken by folks in the next couple days, lets try to plan a stable release. We have some level of testing now from #3023504: Add test coverage for drush config export, which is always good if you want to mark something as stable.

Was reported as Fixed 4 years ago.