We were discussing software versions.

Ideally, we have one or two earlier versions to maintain when the next release is being developed in the current time. And these versions usually differ in the minor part of the dotted quad notation M.m.b.r where M stands for major, m for minor, b for branch and r for revision. This is very helpful towards the development of next release because the earlier versions are not very significantly different from the main branch and the patches made on the earlier branches may all be applicable to the main branch. Since there are not a number of versions, the software release cycles are small and the customers are able to upgrade without delay. The cadence of releases and upgrades means the current main branch has the luxury to break free from earlier designs and take on revolutionary ideas and architecture.

With the introduction of the agile development model and the Continuous Integration and Delivery the software releases, branching and versioning strategy were greatly relieved as there was no waiting time between when the main branch could be forked as a software release. The agile development model helped small teams remain focused on features and the features were incrementally built also with continuous integration and deployment. Only when all the backlog for the feature was satisfactorily burned down, the feature would move into the main branch and the feature branches deleted.  Since the feature was continuously deploy-able and the feature branch was continuously syncing from the main branch the risk of merging the feature branch into the main branch is less risky, Moreover, developers spend time on feature development rather than bug fixes on existing and earlier versions. As the resources and the time for development increases, the business grows as innovation and incorporation are better articulated, Helpful features for customers such as Command line interface (CLI), user interface (UI), software development kit (SDK) and API documentation are greatly improved. Connectors and interfaces to automate some of the customer chores are developed and there is more customer mindshare than ever before potentially increasing the number of customers.  This is the virtuous side of the sustaining engineering as long as the maintenance is not onerous.

Sustaining engineering managers like to draw the software engineering in branches forked from the main branch. Usually these branches are also merged into the main branch or deleted when earlier releases are no longer supported. However, the migration of fixes from the releases branch to the main branch does not need to be all at once and can even be made in parallel as and when the fix is applied to the release branch. This results in the marking of the release branch for delete without any further actions of including them to the main branch.

However, the world is far from these ideal situation and engineers and managers alike grapple to close the difference.
#codingexercise
Find the most frequently occuring gap in an array:
Int GetFrequentGap(List<int> A)
{
A.sort();
Var gapCount = new Dictionary<int, int> ();
For (int I = 1; I < A.Count; I++)
{
    Int gap = A[I] - A[I-1];
    If (gapCount.ContainsKey(gap)){
         GapCount[gap] += 1;
    } else {
          GapCount.Add(gap, 1);
    }
}
If (gapCount.isEmpty()) return –1;
Int max = GapCount.Values.Max();
Foreach (var kvp in GapCount){
   If (kvp.Value == max)
        Return kvp.Key;
}
Return –1;
}