Maintaining commercial MPS libraries is hard

It is a fact of life that maintainers of commercially used MPS libraries, such as mbeddr platform or MPS-extensions, have to maintain multiple versions of the library in parallel, for each MPS version they actively support.

(Well, it’s not really a fact of life because it can certainly be improved, and in the future I want to share my thoughts on how to solve this problem and the related problem of slow uptake of latest MPS versions, but let’s accept it as a fact of life for the duration of this email.)

Let’s take the mbeddr platform for example. There are customers using it with MPS 2021.3, while the latest version that mbeddr platform supports as of this writing is 2022.3 (and the latest version of MPS is already 2023.2). The customers often need a new feature implemented in the platform they are currently using and are willing to pay for it.

So let’s say mbeddr platform for MPS 2021.3 gets a new feature. Of course, it usually makes no sense to have a feature that is there in 2021.3 but disappears once you upgrade to 2022.2. The clients want the feature to exist in newer versions as well.

Each MPS-specific version of mbeddr platform is maintained on a separate Git branch (maintenance/mps20213, maintenance/mps20222, and so on). To forward-port a feature to newer versions, the maintainers have to regularly merge older branches into newer ones: 2021.3 into 2022.2, then 2022.2 into master. This is what is known as a cascading merge.

Cascading merges are quite tedious. Depending on how your project is configured and whether conflicts are expected, you may have to wait until your PR with a feature is merged into the target maintenance branch, then you need to create a separate branch from the maintenance branch, merge the next maintenance branch into it first, then submit a PR, wait until it is reviewed and merged, then remember to submit another PR, and so on. To do all that you have to switch branches a hundred times and remember to specify the correct branches everywhere. And the problem gets worse the more active maintenance branches there are.

No wonder that developers find better things to do while they are waiting, then they get distracted and the cascading merge never completes.

A reusable workflow for cascading merges

As with all the tedious, repetitive things in life, wouldn’t it be wonderful if the computer could do it for you?

That’s why today I present to you a reusable GitHub workflow for cascading merges.

The workflow is designed to be used on push to a maintenance/* branch. It will create a pull request to merge the changes from the current branch into the next one, in alphabetical order.

  • The person that pushed to the maintenance branch (usually the one who merged the feature PR) will be added to the cascading merge PR as an assignee and a reviewer.
  • If there is no next branch, the PR will be created for the default branch (main or master).
  • If a PR for a branch already exists, it will be updated.
  • The PR is based off a separate branch so if there are conflicts you can check out the branch and fix them without messing up the original branch.
  • If you need to exclude a branch (or a whole branch prefix), you can do so. (In mbeddr there are branches for old MPS 3.x versions that are named maintenance/mps3*, putting them alphabetically higher than maintenance/mps20*).

I have submitted PRs to use the workflow in MPS-extensions and mbeddr.core. If you want to use the workflow in your project and need help or an enhancement, let me know.

Thanks to Norman Köster

The starting point of this workflow was me learning that Norman Köster at itemis has successfully automated the cascading merge for the Modelix project. I took Norman’s solution, tinkered with it a bit, and eventually managed to parameterize it and package it as a reusable GitHub workflow. Thank you Norman for paving the way!