对于上图中的gauge，将value与label之间的比例值调整了，调整为1:1.2。这意味着，在新系统中打开老报表，老报表中的这个gauge的value可能会比以前大，二者可能是用户厌恶的效果。
严格来说，这个改动破坏了产品与用户“签订”的协议。用户升级后，以前做得报表的展现出现了变化。
但是我们最终还是这个改了，原因如下：
1. 这个变化很微小，用户应该不会注意到。
2. 如果在这里做兼容性，会导致产品的“较大”的冗余。结合第一点会显得得不偿失。
说实话，在这里我有些迷茫了，或许这样的兼容没有必要；但又或许，我们应该思考一下兼容问题了，找到“兼容”与“冗余”之间的平衡点，好的方法！
或许采用“核心安装包”+“兼容工具包”+“用户主动控制报表升级”的策略可以解决这个问题。
核心安装包：每个版本代码，它不考虑兼容性。报表文件中记录者最后一次保存时使用的解析包版本。在呈现报表时，如果没有这个版本的“兼容包”，就会使用当前版本的核心包解呈现。
兼容工具包：使用每个版本的特色解析“旧报表”。
用户主动控制报表升级：在呈现就报表的界面上，提供“将报表升级到最新版本”的按钮，可以让用户主动升级后再调整报表。
这样做得好处是：
老用户升级时只需要下载两个文件：“旧版本的兼容包”和“最新版本的核心包”。而新用户只需要现在核心包就可以了。区分性的解决了产品代码冗余的情况。
用户主动升级报表，又会提供了老用户丢弃冗余代码的途径。
坏处是：
如果用户不主动升级报表，问题依然没有解决。
用户很懒，未必会因为“去除冗余”而升级报表。而当他们不等不面对“冗余”问题时，可能需要升级的报表已经积累到了一个“庞大的”数量了，甚至因为版本差距过大，已经不能“调整”了。
当新用户导入旧报表时将面临“变形”的问题。当然这个问题可以通过下载“兼容包”来解决。
总之，在“兼容”与“冗余”之间，我们需要一个比较的好的解决策略！