Status detection broken after upgrade from 2.3.4 to 3.5.5

[Herz3h]

BC Break Report

I upgraded from doctrine/migrations 2.3.4 to 3.5.5 breaks migrations detections

Q	A
BC Break	yes
Version	3.5.5

Summary

Introduction of migration_paths breaks detection of executed migrations.

Before upgrade, I had this configuration (yaml):

doctrine_migrations:
    dir_name: "%kernel.project_dir%/src/Migrations"
    namespace: Application\Migrations
    table_name: migration_versions
    name: Application Migrations
    organize_migrations: false 

After upgrade:

doctrine_migrations:
    migrations_paths:
      'Application\Migrations': '%kernel.project_dir%/src/Migrations'
    organize_migrations: false
    storage:
      table_storage:
        table_name: migration_versions

Previous behavior

Running doctrine:migration:status previously reported migrations as executed.

Current behavior

Running doctrine:migration:status now, shows that all my migrations are not executed.

How to reproduce

Install migration v2.3.4, execute some migrations then upgrade to v3.5.5.

Upon digging, it seems the problem is upon using ReflectionClass, getName returns the FQDN of the class instead of the short class name (maybe it used to do this before?):

migrations/lib/Doctrine/Migrations/Finder/Finder.php

Line 63 in 832ef28

$versions[] = $class->getName();

Added screenshot of migration_versions table:

Because afterwards it is comparing executed version name vs available version, but they dont match, one has FQDN while in the DB it says Version2023... only without namespace.

Edit: Found the commit that changed the behavior (3.0 release commit):
d74785f#diff-3ba1cb4b1d3fc85dc36972850335e25c1e714e8dad9f794a0ff79ec7b2a2ec94L67

[stof]

When upgrading to a new major version, you need to run doctrine:migrations:sync-metadata-storage command to migrate the metadata storage to the new format.

doctrine:migrations:status does not automatically migrate the stored metadata (note that any command that modify metadata due to executing some migrations will trigger a storage sync first to ensure they don't corrupt the storage by having a mix of versions).

[Herz3h]

Apologies, I forgot to mention that I had already run that sync command, yet the problem remains. Is the sync command supposed to update the version column in the database with the namespace ?

[stof]

it should, yes