We have an application which contains of multiple composer packages.
A default structure of the site is:
Each package has its own version, f.e. framework is running on v1.5.8 and filemanagement is running on v2.3.8.
To improve our code quality we've started with using a DTAP way of publishing features and bugfixes for packages, so it's possible to test the new features first more profondly before releasing them.
For example: our framework package has the following main branches:
We do have a testing environment now which does automatic builds of the v1.5-test branch (and a staging environment with automatic builds for v1.5-staging). But these builds are failing regularly due to merge conflicts or missing (dependency) code.
At this moment we lose track of what has been merged to which branch already, which means that some features are on the test branch, others on test and staging, others have been merged directly in the version-branch and some haven't been merged anywhere. In Bitbucket we could only mark 1 branch as the main branch (while in reality we have a "main branch" for each main version we've released).
We prefer to have an overview of all the issues who needs to be transferred to another branch (from test to staging or from staging to the version-branch) and this for all of our packages.
How do/would you guys deal with this issue?