Tuesday, April 5, 2016

Backport Bugs

The concept of Back Port exists since we have multiple releases, which are available on the market.  A customer may be using an old releases of our codes.  Back Port means making the code changes on top of the old release and make the code available to the customer.

The new release, of course, is also on the top of the old release.  In theory, if the customer can use the new release, you do not need to provide a back port.

The reason why we have to back port because
  • The new release has not been available since it is not ready.  The customer cannot wait for it.
  • The customer may not want to take the new releases.  
    • It may require efforts to upgrade.  
    • The customization may got lost.  
    • There may be risks due to other bugs or non backward compatible changes
    • They are happy with the existing software as you have done a great job, except the issue they are running into
    • They already have a lot of other backports
  • The issue is blocking and the customer cannot continue using the existing software without having the fix.

How to avoid providing back ports:
  • You release codes often.
    • The new release is available soon, so the customers do not have to wait.
  • Upgrade from an old release to a new release is painless.
    • Each upgrade only introduce small changes
    • The changes are reversable
    • You always have good quality of codes
    • You always keep backward compatible
  • You are able to unblock the customers without providing a backport or upgrade the customer to a new release.
    • Your software is customizable and flexible
    • The customer is willing to get the hot fixes

Why providing a backport is costly?
  • You have to shift the focus
  • A backport may not work for a old release and special fix is required
  • You may need to provide a fix on top of other fixes.  Testing become complex



No comments: