I have two applications, called A and B. The current version of these applciations are 7.x (some customers run 7.1, others run 7.2, ...). Both applications use a same common framework (let's call this C), like this:
+---+ +---+ | A | | B | +---------+ | C | +---------+
Because of some important new customers, I want to have the functionality of A and B in one big application. Merging A and B into one application is not possible, so I am now trying to integrate the functionality of A into B. So far so good, but I starting to encounter some problems.
First of all, customers that only use the base functionality of B are not interested in all the new functionality of A that is added (and which causes additional overhead for them). They just want to upgrade their version B with support for new Windows versions, ... and maybe also want all the nice functionality that is added to C (the common framework) as well.
Second, customers that are currently using application A, don't want to directly move to application B, although the combined functionality of A+B would help them in the long term. For easy upgrades, they want to stick with A, and even see some improvements in C.
Third, all of the developments I'm doing in B might have an impact on the common layer C. E.g. in order to improve performance of a module in B, I have to refactor a module in C, but since C is also used in A, I need to do much more work. Additionally, A is an older, less-structured application, and every change in C might make A more unstable.
Question is how to proceed? I am currently thinking on splitting B in a 7.x release (I could still do some minor developments here and release 7.3, 7.4 in the coming years if needed), and an 8.x release (which would contain all the new functionality). To solve the problem of the common layer, I could also split C into an old C (7.x) and a new C (8.x). This gives the following result:
+-------+ +-------+ +-------+ | A 7.x | | B 7.x | | B 8.x | +-----------------+ +-------+ | C 7.x | | C 8.x | +-----------------+ +-------+
Application A would not evolve anymore and would stick to the 7.x version of the common layer C.
Splitting C means that all developments in C will either not be seen in the old A and B (which would still be release 7.x), or if they must be done in release 7.x of A and B, would require doing the developments in both releases.
An alternative could be to split B into B 7.x and B 8.x, but this would limit the refactoring possibilities in C, and actually only solves the first two problems.
Does anybody have any experience with such a kind of major release change? Any other ideas?