依赖升级、框架升级、语言升级

    我们在选择依赖库的时候，通常会选择那些比较成熟的依赖。成熟的框架、组件、库，往往采用语义化版本的形式来发布。其遵循的版本号格式是：主版本号.次版本号.修订号，如1.2.3中的1是主版本号，2是次版本号，3是修订号。其版本号递增规则如下。
    ◎　主版本号：当你做了不兼容的API修改。
    ◎　次版本号：当你做了向下兼容的功能性新增。
    ◎　修订号：当你做了向下兼容的问题修正。注意：有些框架并不会严格按照这种形式来发布，如React框架的版本号直接从0.15.6改为了16.0。

    依照这种形式，在针对依赖的升级时，我们会采取相应的应对措施：
    ◎　当修订号发生变更时，通常只是进行一些Bug的修复，不需要我们做出响应。
    ◎　当次版本号发生变更时，往往可能会发生一些API变更，我们要视向下兼容情况来决定是否跟进。
    ◎　当主版本号变化时，可能有些API已经不存在了，我们需要大量地改动应用。
    当发生修订号变更和次版本号变更时，我们可以视情况不予理睬，或者有选择地更新，如果该库提升了性能，那么就可以更新；如果该库修改了我们未使用的API的bug，也就没有理由再更新了。

    依照这种形式，在针对依赖的升级时，我们会采取相应的应对措施：
    ◎　当修订号发生变更时，通常只是进行一些Bug的修复，不需要我们做出响应。
    ◎　当次版本号发生变更时，往往可能会发生一些API变更，我们要视向下兼容情况来决定是否跟进。
    ◎　当主版本号变化时，可能有些API已经不存在了，我们需要大量地改动应用。
    当发生修订号变更和次版本号变更时，我们可以视情况不予理睬，或者有选择地更新，如果该库提升了性能，那么就可以更新；如果该库修改了我们未使用的API的bug，也就没有理由再更新了。