3

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?

Improve this question
3
  • How many different active support branches do you currently have to maintain?(Roughly? 3? 30? 300?)
    – Doc Brown
    Commented Sep 7, 2020 at 12:02
  • 2
    "What's a good way to deal with this situation?" – What makes you think there is one? Backwards compatibility is pretty much one of the hardest problems in Software Engineering.
    – Jörg W Mittag
    Commented Sep 7, 2020 at 12:15
  • @DocBrown About 15. Of those, about 4 regularly receive updates.
    – Andreas T
    Commented Sep 7, 2020 at 13:13

2 Answers 2

Reset to default
3

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:

Improve this answer
4
  • The two points you bring up are certainly something to consider. "Gradually modernizing" is an option, yes. The issue it brings is that the "tech break" would occur over multiple branches. For example, a dev might create a bug fix on two files A and B on release 1. Release 2 modernized file A, so part of the fix would have to be rewritten. Release 3 modernized file B, so a third version of the fix would have to be created.
    – Andreas T
    Commented Sep 7, 2020 at 15:24
  • The second point is not something within my control. There is a movement towards more "active development" and less "legacy support" but I am not aware of specific plans to reduce the number of branches significantly.
    – Andreas T
    Commented Sep 7, 2020 at 15:25
  • 1
    @AndreasT, the "gradually modernizing" could also start with only the new features in your software (so bugfixes on old releases will have less to no impact from it) and existing code only gets refactored into modern code if there are enough tests proving the modernization is a true refactoring (no change in behaviour). That test set should then also help with the confidence in applying a bugfix coming from an older branch.
    – Bart van Ingen Schenau
    Commented Sep 8, 2020 at 12:14
  • @BartvanIngenSchenau That's fair. The issue of having to do twice the work might still come up but then it would be safe at least. Thank both of you for contributing.
    – Andreas T
    Commented Sep 9, 2020 at 18:17
1

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.

Improve this answer
1
  • "Just rewrite your entire code base" is not really helpful advice. Besides the unrealistic amount of work it would require, support branches for the last 10 years would still exist and need to be supported separately, adding even more work until all of those can be discontinued.
    – Andreas T
    Commented Sep 9, 2020 at 18:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.