Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I installed Drupal 8.6.2 with composer and then migrate_upgrade, using "composer require drupal/migrate_upgrade.
I got migrate_upgrade version 8.x-2.0-beta1, but the version on the project page is 8.x-3.0-rc5 from August 17.
Why did I get a version that is not listed on the project page?
Here are the full instructions on linux, assumming composer is in the path, and you have write permissions on /var/opt:
mkdir /var/opt/composer
composer create-project drupal-composer/drupal-project:8.x-dev --stability dev --no-interaction /var/opt/composer/drupal8
cd /var/opt/composer/drupal8/
composer require drupal/migrate_upgrade
cd web/modules/contrib/migrate_upgrade
cat migrate_upgrade.info.yml
Result: version: '8.x-2.0-beta1'
Expected Result: version: '8.x-3.0-rc5'
Comments
Comment #2
heddnThat's an old version. You might check your requirements and see if it is pinned currently to that major version.
Comment #3
alex.a CreditAttribution: alex.a commentedComment #4
alex.a CreditAttribution: alex.a commentedI don't know what you mean, "check the requirements and see if it is pinned currently to that major version". I did it again in a fresh install of drupal8 and got the old version again. I updated the description with full instructions of what I did.
I'm not really familiar with composer and I don't know how composer selects what version to install. I just followed the instructions for installing drupal and the migration modules.
Comment #5
mmjvb CreditAttribution: mmjvb as a volunteer commentedUse 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
Comment #6
clemens.tolboomI 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'.
Comment #7
heddnThere 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.
Comment #8
mmjvb CreditAttribution: mmjvb as a volunteer commentedThe 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.
Comment #9
heddnAh, 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?
Comment #10
mmjvb CreditAttribution: mmjvb as a volunteer commentedAlthough 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.
Comment #11
clemens.tolboomRegarding 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 :)
Comment #12
mmjvb CreditAttribution: mmjvb as a volunteer commentedAgain, 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.
Comment #13
mmjvb CreditAttribution: mmjvb as a volunteer commentedComment #14
clemens.tolboom@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
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).
It's quite lame we cannot pin branches to core version in a `back to the future` way.
Comment #15
heddnre: #14
That is kinda my point in:
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.
Comment #16
alex.a CreditAttribution: alex.a commented"So, the only "fix" for this is to 1) update docs or 2) release a stable 3.0."
I think you should have immediately re-released 8.x-3.0-rc5 as stable, because it is a version that somewhat works, and is the only version listed on the project page. Installation and Migration are the first impressions of a new Drupal release to new and existing users. Both are broken in Drupal 8. Fixing them should be top priority.
Comment #17
heddnIf 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.
Comment #18
alex.a CreditAttribution: alex.a commentedI verified that composer now gets the 3.0 release, so this is fixed.
The composer commands should have --no-dev flags to not get the dev packages:
Comment #19
mmjvb CreditAttribution: mmjvb as a volunteer commentedWas reported as Fixed 4 years ago.