core migration inconsistencies about flow-development-collection HOT 1 OPEN

Comment created by @bwaidelich:

Carsten, thanks for your feedback.

{quote}
Is it realy needed to make a difference between core:migrate / doctrine:migrate
{quote}

Yes I think so because they have a different use case: While you should execute doctrine migrations whenever you can (at least after pulling a new version), running core migrations should only be required when upgrading a flow/neos distribution to a new version

{quote}
their generic arguments should be unified (f.e. --verbose vs. --quiet).
{quote}

I agree and FLOW-216 would come in handy here

{quote}
Generic "--dry-run" argument
{quote}

That would be nice. But in contrary to doctrine migrations we'd have to apply the migration(s) and then revert them (by discarding all local changes) -> not so easy and in any case you can always revert by resetting the working copy

{quote}
"flow core:migrate --status" shows "migrated" or "not migrated, skipped". "not migrated, skipped" is a mixup and not clear to me
{quote}

The problem here is: With the old core migration handling (prior to 3.0) we did not create a commit if a migration did not produce any changes. So it's currently impossible to tell for sure whether a migration has been skipped (b/c it had no effect) or whether it wasn't executed at all.
With 3.0 this issue is fixed and all migrations will be tracked in the git log. For the core packages we'll take care of marking those migrated before releases (see https://review.typo3.org/#/q/status:open+topic:recent-core-migrations)

from flow-development-collection.