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:
- 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.
- 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?