Creating a solution patch in D365 Power Platform, why would you do so?

Note: I’m a firm believer in releasing only managed solutions to testing and production environments and maintaining an unmanaged solution on the development box only, therefore this post is based on the MS best practice architecture of exporting managed solutions for distribution.

To understand solution patches think of them in the direct definition of what a patch is, something to mend or fix up a weak or broken point. For example a complete wall with a hole or a small missing piece in it would require a patch not a new wall. Solution patches are meant to fix up or complete a deployed solution, not to deploy new functionality; I repeat, they are not meant to deploy new additional functionality. This generic definition should be your rule of thumb when deciding whether to create a patch and release that or a new major version release.

On the other hand whether you are in a situation of actually needing to release a patch level fixes or working on a new sprint in your project to release for UAT after the first version of the solution has already been release, creating a patch is always a good idea to keep your new sprint functionality separate from the main solution until you decided to release the functionality, as that helps a great deal in identifying/reviewing the changes done before they are merged into a new version of the solution( more on major releases to come in future posts)

In order to create a patch for an existing solution in your development box. Select the base solution and click on Create patch

You get the option to change version, ideally you should let the system recommended one stay as it is managed in order of creation if you create more than one patch