DocApps are used to package various elements for customization (such as custom Object Types, Lifecycles, etc.) so that they can be ported from one repository to another easily. It is usually not an issue when a DocApp is installed into a repository for the first time. Consider that a DocApp was developed in a DEV repository and then archived and installed into the QA repository. At this point the QA repository contains everything that was packaged in the DocApp.
Suppose that testing in QA exposes a problem with a lifecycle. We go back to DEV and fix the problem. Now, we archive the DocApp again and install it in QA. If we are using the default installation options on the DocApp, this will create a new version of the lifecycle! It is likely to lead to a problem.
A DocApp contains installation options and the options that address conflicts with existing duplicates are called Upgrade Options. Upgrade options include overwrite, version, overwrite if newer, and do not overwrite. Once you start looking at each item within the DocApp the choices may not be very difficult. The problem may arise if you decide to trust the default upgrade options.
In general (there are some exceptions), sysobjects have version as the default upgrade option. The tricky part is that lifecycles and workflow templates are also sysobjects. Usually, one doesn’t version lifecycles and workflow templates. However, default upgrade options will version lifecycles and workflow templates when the DocApp is installed again in a repository after the first time.
If you are creating a DocApp containing lifecycles and/or workflow templates the least you can do is to review the upgrade options for these objects. More often than not, this will be time well spent.