向前兼容与向后兼容

向前兼容或者叫向上兼容，向未来兼容
向后兼容或者叫向下兼容，向过去兼容

讨论兼容性问题，表面上是说两个东西的关系，但其实隐藏了一个前提，就是依赖性，而依赖是有方向性的

我们说A依赖B，表达的意思是A的正常工作是依赖B的，同时也是一种配合关系，若这种配合关系可以错位，其实就是实现了某种兼容

假设A依赖B可正常工作，后续迭代后，A1依赖B1时可正常工作的，再次迭代后，A2依赖B2是可正常工作

A --> A1 --> A2
B --> B1 --> B2

现在讨论B的兼容性，B迭代后是B1，如果A可以依赖B1可正常工作，那么意味着B做到了向后兼容，也就是向过去兼容，若果A2依赖B1是可以正常工作的，那么意味在迭代到B1时，对未来发生的变化做到了兼容，所谓向前兼容。

再说A的兼容性，A迭代后是A1，如果A1可以依赖B正常工作，那么意味着A做到了向后兼容，如果A1依赖B2页可以正常工作，那么A做到了向前兼容。

其实A1可以依赖B正常工作，也可看成是B做到了向前兼容，A1依赖B2页可以正常工作，可以看成是B做到了向后兼容，推广可以得到，如果B始终保持向后兼容，那么A就一定是向前兼容的，反之亦然。

但实际操作中，B是A的依赖，所以B迭代成B1，才会出现A1，因为如果没有B1，也就是B没迭代，A的升级后不能称之为A1，还是A。所以是B先迭代到B1，A可以依赖B1工作，意味着B1做到了向后兼容，一般不说A是向前兼容。
那么当迭代A到A1时，如果A1也能依赖B正常工作，那么A1做到了向后兼容，一般不说B做到了向前兼容。

通过推广可以知道，如果A和B都做到了向后兼容，那么意味着，同时A和B也做到了向前兼容

不过大多数场景中，比如glibc，一般是B做到了向后（过去）兼容，意味着A可以依赖当前或者新的B（未来）正常工作，但不能依赖旧的（过去）B。也相当于A面向未来兼容了，向前兼容（一般不这么说）。
glibc做到了向后兼容，新的bin不能使用旧的glibc工作，但可以使用新的glibc进行工作

也有场景是A一直做到向后兼容，比如B是数据，数据文件格式发生了变化，相当于B变成了B1，让A能读取B1一般是困难的，大多是A1要能做到即能读取B1又能读取B，意味着A做到了向后兼容。也相当于B向未来兼容了，向前兼容（一般不这么说）

有时这种兼容关系比较容易搞混，因为角度和依赖关系的分析不一样会得出完全相反的结论，比如下面这个例子：
比如一个数据生产者P，生产的数据D，一个数据消费者C，而P和C却是同一个模块M的两个角色。
依赖关系来看，C是依赖P的，因为P生产数据后，C才能消费
C --> C1
P --> P1
如果P的升级导致数据格式的变化，生产D1，但C依然可以消费P1生产的数据D1，可以说P的升级做到了向后兼容
但深入分析一下，P的升级其实是M的升级，M要生产新的数据格式，就升级到了M1，若此时C中的M还能读数据D1，那么M是做到了向前兼容，从P的角度看，P的升级做到了向前兼容吗？

其实M的兼容性是相对D来说的，也就是M1生产的D1，但M能够读取D1说明，M是向前兼容了。
M --> M1
D --> D1

但这就是一次升级，却有两种说法，到底这次升级是实现了向前兼容还是向后兼容很容易搞混，所以不同的角度，会导致不同的答案，但本质上还是概念的区分