How to visualize compatibility between different versions of different software?

Question

I have five different software products (let's call them A, B, C, D, and E), each with several different versions. Each version of one product is compatible with at least one (and usually several) version(s) of every other product. These version numbers are independent. For example, A 1.2 isn't necessarily compatible with B 1.2. I cannot change this numbering scheme. Another interesting feature of the compatibility is that each product is always compatible with a continuous range of versions. For example, if C has versions 2.1, 2.2, 2.3, and 2.4, no other product will ever be compatible with only 2.1 and 2.4; they will always be compatible with everything between two versions.

Here's an example of the sort of data that describes the compatibility:

A 1.1 - Compatible with B 6.1 - 6.3. Compatible with C 2.2 - 2.3. Compatible with D 1.4 - 1.5. Compatible with E 1.3 - 1.5.

I want to create a visualization to represent this compatibility. The most important features of this visualization are that it should, ideally, fit on a single page (maybe it would have to be a big page) and be optimized for answering the question "I have this version of product X. Which versions of the other products can I use?"

Here's some options I've considered:

A "compatibility matrix". Each row would represent every version of each 5 products (it would be quite a lot of rows). Each column would just represent a product. Each cell would then contain a range, indicating the versions of the column product that are compatible with the version of product on the current row. The problem with this is that it would be very long and there would be lots of duplicated information (it's not taking advantage of the fact that all compatibility is reciprocated). There's also wasted space from rows for product X version Y.Z and columns for product X (there's no need to communicate which versions of product X are compatible with themselves as that makes no sense).

Another option I considered is a "compatibility bar graph" something like the following:

In this instance, you would just draw a horizontal line at some point and the boxes intersected by that line would describe a set of compatible versions of all products. I think this would be very difficult to create because I'd need to figure out how tall each box will need to be and make sure there's enough space to accommodate all the other compatible versions of the other products and make sure all the overlapping is correct. I also don't even know if it would work - maybe there's some instance where it wouldn't be able to accurately represent some valid combination (but I haven't discovered such a case yet).

Finally, I also considered something kind of like a "compatibility map". It would look like this:

As you can probably tell, this seems like kind of a nightmare to create. I would want to lay it out to avoid crossing any lines, but I'm not even sure that's feasible. Also it would just be horrendously busy because there would be so many lines and so many points (one point for each version of each product).

With that in mind, I'm wondering if there is any option I haven't considered for representing something like this. Thanks for any suggestions!

Answer 1

Given the end goal of simple lookup conditional on a specific version of a specific product, a table may be suitable. Graphs are good to finding patterns, but tables are better for finding exact values.

Here is a quick and dirty mock-up in an ascii table that I think would be alright for the job. Here you would just have different tables given a different starting software product.

         B         C     D
----------------------------
A 1.1                    2.2
                         2.3


A 1.2   3.4       1.5
        3.5
        3.6

A 1.3   3.6       1.6
        3.7       1.7
        3.8

A 1.4   3.8       1.7
        3.9

Graphs are good though for seeing patterns, so a set of graphs may be useful in helping customers choose which software best suits there needs given the compatibility constraints. Here is a simple paneled scatterplot approach, with the A version of the software on the Y axis, and different panels show different software version compatibility pairs.

I bet you could make a fairly nice planar (i.e. few lines crossing) network diagram to depict it using an irregular layout (if you have products cluster with one another and then lines between the clusters), but the scatterplot is easier to whip up in a few minutes, and organizing the panels I imagine will do just as good a job as a network diagram.

---

R Code to reproduce image

library(ggplot2)

con <- textConnection("
Prod1 It1 Prod2 It2
A 1.2 B 3.4
A 1.2 B 3.5
A 1.2 B 3.6
A 1.3 B 3.6
A 1.3 B 3.7
A 1.3 B 3.8
A 1.4 B 3.8
A 1.4 B 3.9
A 1.2 C 1.5
A 1.3 C 1.6
A 1.3 C 1.7
A 1.4 C 1.7
A 1.1 D 2.2
A 1.1 D 2.3
") 

MyData <- read.table(con, header = TRUE) 

p <- ggplot(MyData, aes(x=as.factor(It2), y=as.factor(It1))) + 
    geom_point(size=12) + facet_wrap(~Prod2, scales = "free_x")
p <- p + labs(x = "Version", y="A Version") + theme_bw()
p

Answer 2

I've run across this problem a few times in my 20+ years as a software developer. Essentially each piece of compatible software adds a dimension to the dependency tree of requirements. For 3D I could see this being implemented as a rubix cube of versions, where shapes would form like 3d tetris blocks. The central dependency could then show it's interconnectivity between up to 4 other dependents, shown as shapes to each of 4 cardinal sides. This might also be helpful; https://en.wikipedia.org/wiki/Dependency_hell It's important to see the dependencies themselves as relationships/edges on a graph/mindmaps, and the individual versions themselves as the data points.

Here are some 3-way examples that' I've run into recently: In this case we don't need to worry about compatibility of 2 vs 3, only 1 vs 2, and 1 vs 3. This simplifies the permutations, and is more of a Mickey-Mouse ear or CO2 atom dependency graph.

1. Mongo Server Version
2. C#.NET code driver version (hooks to Mongo servers #1)
3. Python driver version (hooks to Mongo servers #1)

Example of driver compatibility table 2D

https://www.mongodb.com/docs/drivers/csharp/current/compatibility/#std-label-csharp-compatibility-tables

Same thing but Python dependencies, both need to interface simultaneously against server, so you get a 3-way dependency

https://www.mongodb.com/docs/languages/python/pymongo-driver/current/compatibility/

Depending on your "starting point" (what versions do you currently have that are running together), there also (sometimes) exists a feasible upgrade path at which one could follow to get to the final most upgraded state (or most stable point along the way), without actually breaking compatibilities. In this case there is a "right answer" or the path with that would bring you up to date to target versions with the fewest number of changes.

If you lay out the tables in 2D, like the mongo ones have done, then usually the correct path is a stair-stepped one, where you upgrade one dimension/app as far as it will go (to highest version supported by your other dependencies), then you upgrade the server to highest version supported by the new stair-stepped app version, rinse and repeat.

It's worth noting that this particular problem is a kind of "code smell" or "bad architecture smell". It probably means that either you are in the middle of a big merge or paradigm changeover, or your technical architect or director is smoking crack. (aka, if you're experiencing this problem you should "ask why 5 times", and consider deprecating or rolling one-or-more of these disparate tools into each other to unify the tech expertise and ongoing management costs, one of which is dealing with upgrade version hell on any MORE THAN 2 or 3 interlocked systems at once)