0

We have an application which contains of multiple composer packages.

A default structure of the site is:

  • src/
    • application/
    • vendor/
      • vendorname/
        • framework/
        • filemanagement/
        • ...

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:

  • v1.0
  • v1.0-test
  • v1.0-staging
  • v1.5
  • v1.5-test
  • v1.5-staging
  • v2.0-alpha

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?

0

Don't have version branches. They are misleading.

Stop supporting old versions.

Have a development branch, which you deploy to your test environment and a master branch which you publish from.

When you complete v0 in development you merge to master and publish it as v1. development becomes vNext and when you publish it gets a version number.

If you need to a hotfix on an old version, only then do you branch from that point in master and release a v1.1 to test this, deploy it to your test env instead of development.

Avoid this if possible, you want your users to upgrade rather than have to support old versions. If its an internal library then force yourself to upgrade!

5
  • 1
    Version branches are absolutely critical to support multiple versions, and old version branches should always be merged to new version branches. For example, if I need to support major versions 5, 6 simultaneously, there will be version branches v5 and v6, and base the develop branch out of v6. If you need to fix v5, make it directly on v5, tag it, then merge v5 to v6, then v6 to develop (assuming the same bug appears over versions). Never bug fix on develop and backport it to the old version. – Michael Tsang Aug 14 '20 at 4:23
  • no, dont do that. as soon as you have different versions they will start to diverge, code fixes on one cant be merged back to the other and expected to work – Ewan Aug 14 '20 at 6:15
  • New versions should never diverge from old version because we never add features into old version but not in new version. New version is always ahead of old version in git terminology. – Michael Tsang Aug 14 '20 at 10:13
  • yes but its not the sum of its previous versions, for example in adding a feature I might refactor some classes, I then fix a bug in a previous version that uses the old version of those classes. I cant simply merge the fix back to master or the new version. I have to write the fix twice. – Ewan Aug 14 '20 at 10:34
  • the 'misleadingness' of version branches is the idea that you can merge them like other branches, rather than treating them as seperate code bases – Ewan Aug 14 '20 at 10:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.