“Support branches” and major tech update

Question

Our software product promises to support major releases with bug fixes for X years after the release, meaning that in our git repository, we keep permanent "support branches" for every major release next to the master branch. In general, bug fix tickets are handled as "these have to be fixed for release A", are fixed there, and then the fix is "cherry picked" up every release to the current one.

Due to this, the company policy has been to not perform any big dependency upgrades, be it with the version of the used programming language, frameworks, libraries, or other. Also, code shouldn't change to much. Everything to make sure that the cherry picks require none or as little as possible manual work.

This recently changed as we cannot afford to keep using all this tech that is mostly not supported in any way anymore. Libraries, compilers, and everything else are going to be updated. This however, poses the question on how to deal with these bug fixes for older releases in the future.

Basically, the two extremes of the spectrum are:

1. Ban all use of any new features. Pretend like the libraries and compilers still have the same version from 25 years ago. Carry around this tech debt for another who-knows-how-many years.
2. Rewrite the entire code base with new features in every aspect. Have a top modern code base (for a bit). Bug fixes on older releases can be cherry picked up to the last release before the "big break" and have to be developed separately after that, so basically you'd have twice the work for those cases.

Both clearly have pros and cons and of course there are possible solutions in between. What's a good way to deal with this situation?

Answer 1

I would first try to make a statistics:

• how many hours did your team invest in bug fixing for older releases, let us says, last year, and how much time was invested to transfer those bug fixes to the different support branches?

• now estimate how the second of those numbers would change when you had to maintain an additional "new technology" branch.

• finally, multiply this number with the number of years you expect having to maintain the "old-technology" branches.

That should give you a rough cost estimation for the strategy of a "new technology" rewrite, which should be the basis of making a decision whether these costs are worth it, or not. (If this is balanced by cost savings through the usage of the new technologies is hard to foresee. However, it at least it should give you an indicator what to expect).

However, there are more things to consider here:

• Can you gradually modernize? If that is possible depends heavily on the tools and environment you are using now and in future (and sometimes on putting enough thought into it). In my experience, this can be a very cost-effective approach, whilst huge rewrites are seldom economically justified and bear a high risk of ending in a desastre.

• Can your company reduce the number of active support branches? This is probably a contractual problem, but it is not uncommon to have a clause in maintenance contracts where customers are obliged to switch to a newer version in case they want further support and bug fixes for the product.

The latter will not solve your issues with switching to a newer technology directly, but it may reduce the time for which you have to support the older technology, and it may help you to free developer resources for tasks like porting bug fixes to the new tech stack.

Some related SE.SE questions:

• How to introduce new language features in a legacy source code?

• Have you ever been involved in a BIG Rewrite?

Answer 2

Cherry picking is a lie. Anytime you do it you risk and have to test for compilation and other errors you may have introduced. Updating shouldn't add qualitatively to the problem.

Instead of cherry picking, separate code into libraries. You can then fix bugs in the latest version of a library and update multiple support versions of your code to use the latest library.

The same approach can be used for some major changes.

Some of your libraries will be problematic and need more than one version, but many will hopefully be unchanged or backwards compatible.