Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TASK: Followup #5371 remove legacy CopyNodesRecursively command #5453

Open
wants to merge 3 commits into
base: 9.0
Choose a base branch
from

Conversation

mhsdesign
Copy link
Member

And provide transparent conflict when attempting to publish legacy copy nodes

Upgrade instructions

Review instructions

Checklist

  • Code follows the PSR-2 coding style
  • Tests have been created, run and adjusted as needed
  • The PR is created against the lowest maintained branch
  • Reviewer - PR Title is brief but complete and starts with FEATURE|TASK|BUGFIX
  • Reviewer - The first section explains the change briefly for change-logs
  • Reviewer - Breaking Changes are marked with !!! and have upgrade-instructions

* This layer can be removed if there are no legacy events expected during rebasing
* @return iterable<EventEnvelope>
*/
private function triggerConflictForLegacyEvents(EventStreamInterface $eventStream, bool $dropLegacyEvents): iterable
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this might not be soo clever after all because this enforced to use of force and later in the code during the forced rebase other changes which were not communicated might also be dropped.

So maybe its just best to silently ignore any CopyNodesRecursively and basically auto drop them for publish, discard and rebase?

We have said for 3 betas that this will happen ...

@kitsunet
Copy link
Member

Yep, fine by me

While causing a conflict and letting it be solved via force is clever, it might have more negative user side effects:

Because of the force flag, any actual conflicts for later changes will be dropped and the user wouldnt know about them because there was just one conflict communicated.

Instead of solving this more delicate by merging this conflict with the other possible conflicts we decide to just ignore the CopyNodesRecursively as this was communicated for 3 betas.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants