Offer the possibility to log any metadata deletions to a destructiveChangesLog.xml

[René Görgens]

Hi Scott,

I’ve seen issue #1796 but here’s my take.

While it is somewhat mind-boggling to consider the full implications of destructive changes in a deployment lifecycle (cf. #1688), especially with SFDX source tracking, it would be great if there was a simple mechanism empowering the individual developer to keep track of deletions.

I’d like to keep track of metadata refactoring and resulting deletions in a destructiveChangesLog.xml, with the following basic assumptions:

• Usable with MDAPI or SFDX
• Usable with or without VCS
• The developer doesn’t necessarily have the right to migrate changes to upstream environments

Use cases:

• With VCS, the developer wants to consciously decide which destructive changes to include in his pull request (if any) by selectively promoting them from destructiveChangesLog.xml to an actual destructiveChanges.xml
• Without VCS, the developer wants to selectively promote destructive changes from destructiveChangesLog.xml to an actual destructiveChanges.xml for a specific deployment

Does it make any sense?

To facilitate the merge, I’d actually want the developer to include destructiveChangesLog.xml in the pull request so that I have an insight into deleted metadata and can re-evaluate at merge time whether the submitted destructiveChanges.xml (if any) makes sense. So under this idea, destructiveChangesLog.xml should not be edited.

[Scott Wells]

Duplicate of #1796.