At our company we have a monolith PHP application which has been broken down into multiple (self developed) packages around the (self developed) framework package.

This application isn’t a SAAS solution, so the application is installed at the clients domain when developing their websites.

For each package we have a structure like this:

  • StackOverflowController
    • StackOverflowPackageController
      • Controller

In the example above the StackOverflowController can be easily customized on the application side. The StackOverflowPackageController is defined in the package and the Controller is defined in the framework.

Our biggest problem is now that we have a quite large amount of different packages (with a large amount of versions). Since last year every day is checked if the code has changes and a new version tag is being created.

We are facing the following issues:

  • Due to the number of clients from over the years, there’s an enormous number of different versions of our application active. So, when we fix an issue for client A, the package is not always upgradable and the error won’t be fixed without fixing it again.
  • Some packages are tightly coupled to each other so the application breaks when you update one of the packages, but not the other
  • We’d like to move onto SemVer, but we don’t know exactly how and who will be responsable for that job to determine the kind of version type.
  • Also when someone fixed a bug in v1 he needs to create a PR for every child branch and merge it, which is often forgotten.
  • When person A introduces a new feature and person B too, in SemVer the next minor version has already been taken.

Conclusion: How are you dealing with a non-SAAS solution divided in multiple packages and managing when en to where bugfixes or features should be merged?

Your Answer

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

Browse other questions tagged or ask your own question.