Migration command cannot migrate and publish stories with unpublished changes

[FabianKoder]

Not really a bug, more of a missing flag/feature or unwanted behaviour.

Current behavior:
There are multiple possible options for the --publish flag - the one that would probably come closest to the behaviour we would expect is published-with-changes. But, the following use case makes this option not really usable:

We have stories that have content updates (unpublished changes) we don't want to be visible yet, but we basically want to apply the migration to the published and the draft version and then also publish the migrated published version.

Imagine the following case:

Story A has a field test with published value This is a Test and unpublished draft value Testing. Now, having this migration:

block.test = "[MIGRATION TEST] " + block.test;

Would either result in publishing all unpublished changes (not only appending "[MIGRATION TEST] " to the already published test value) when using the option published-with-changes, or not publishing unpublished changes at all when using the published option.

The underlying problem then is that we would need temporary compatibility code that would exist in our frontend during migrations (so it can understand the old and new data format) to stay there forever, since we cannot control when our editors will publish the next version of an edited story (if ever), but we also cannot publish the migrated draft version of the story for them.

Expected behavior:
There should be an option to the published flag that yields the following behaviour:

• Published version's field gets updated with the value [MIGRATION TEST] This is a Test and the story will be re-published so the updates are visible
• Draft version's field gets updated to [MIGRATION TEST] Testing, which is only visible to the editors.

This also means there are potentially two completely different results to a migration depending on the published or the draft version, but that should not really matter since you should want idempotent migrations anyways.

The workflow for the CLI then would theoretically be something along those lines:

• Get published version of story
• Run migration on published version
• Publish the migrated story
• Get draft version
• Run migration on draft version
• Save migrated story as draft

Depending on whether the flow above is easily possible with the API or not, there would also be a hacky workaround flow:

• Get and keep draft version in memory
• Get published version of story
• Override draft data with published data via API
• Run migration and save
• Publish
• Override current data with saved draft version data via API
• Run migration again and save

Steps to reproduce:
Should already be sufficiently explained in "Current behaviour"

Related code:
N/A

Other information:
N/A