We have a lot of “release branches”, e.g. with pulpcore there is 3.14, 3.15, 3.16, 3.17, 3.18, 3.19, and main. For each of these branches we have the responsibility of:
- backporting a fix to every branch in-between
- ensuring the plugin template is always up to date (which changes daily now)
- releasing all versions at once so the bugfix is always available when upgrading to any newer version
Across the project, we likely have 30ish release branches, and with the CI taking 30-50 minutes for each backport on each branch, backport of the plugin template, or release, a huge amount of our time is tied up in release engineering.
We need to find a simpler way as I believe we will soon have a CI that is so clogged up with these types of jobs we can’t make normal dev changes at a reasonable rate. I suspect we are very close to that point or we’ve already reached it.
So I propose we apply the textbook solution to this problem and use an Long Term Support (LTS) branch so that for each project we only have two branches to maintain,
the release branch. Each plugin would figure out for itself what the LTS version should be.
To transition into this type of arrangement we would:
- Designate one LTS branch per component, e.g. pulpcore, pulp_rpm, etc
- Have the plugin template auto-apply machinery apply to that LTS branch and main only (instead of everything in between)
- We only continue backporting and releasing to the LTS
Like most projects, e.g. Django that declare an LTS, we would declare a new one in the future and expect the new LTS to replace the old one. Those users who want to stay with the LTS can upgrade from one LTS directly to the next, e.g. how Pulp itself upgraded from Django 2.2.z (the old LTS) to Django 3.2.z (the current Django LTS).
I know there are many reasons why we probably “can’t do this” however I believe we cannot continue the direction and policies we currently have. This will be a controversial and challenging change, so feedback on it is very welcome.