第三方包使用标准
本文介绍第三方包使用标准
说明：在Macula平台的开发中，已经使用了一些第三方开发包，对于这些包的名称和版本都在Maven的pom.xml中有严格的定义。对于需要修改和调整第三方包的情况，需要遵循如下标准。
版本更替标准
第三方包在项目的开发和维护期，会因为Bug修复、功能提升、性能提升、架构变化等多种原因，会进行版本的升级。但项目中是否需要跟随最新的第三方包的更新，需要按实际情况考虑。
- 原则上不允许由高版本变更为低版本。
- 对版本的小版本号更新（比如由3.1.0升级到3.1.1），由于小版本一般为Bug修复、性能提高是产生，在保证升级后不影响编译出错的情况下，备案后允许升级。
- 对版本的大版本号更新（比如由3.1.0升级到3.2.0或升级到4.1.0），由于大版本号一般在增加功能、架构变化时产生，对此类升级需要严格测试，并由版本更新提出者提供详细的测试说明，在经过架构小组讨论审批备案后允许升级。
- 不允许使用通过获取第三方包的源代码并修改后，自行编译的开发包。
删除标准
在项目的开发和维护期，因为项目的变化，可能对原来使用的第三方包不再需要的情况或其他原因，会存在对已使用包的删除问题，需要按下列原则考虑。
使用策略发生变更，导致不再适用于项目
对于第三方包，在使用策略上发生变化，比如由开源转为闭源、不再维护、由免费改为收费等等情况下，将不再适用于项目中，此时变更可有架构小组提出，并商议审批并备案后，允许删除。此时相应的项目代码，在删除后影响的代码将需要修改测试，以适应删除开发包后的变化。
项目因调整，不再需要该第三方包
对于项目不再需要的开发包，由项目小组提出，并交由架构小组讨论审批备案后允许删除，但需要保证删除该开发包后，其项目代码不受影响。
新增标准
因项目开发需要，存在新增第三方开发包的需要，对于这些新增包的需求，要严格检测是否与已使用的开发包冲突等多方面的考虑，需要遵循列原则标准。
- 对提出需要增加开发包的项目组，需要提供新增包的名称、版本以及可通过Maven获取的仓库点。
- 对新增的开发包，需要提供详细的介绍说明，可通过介绍会的方式，引入开发包的原因、测试报告、使用样例、以及在项目中的使用原因等。
- 引入新的开发包后，需要对项目已有的开发包是否存在冲突以及是否导致项目产生不稳定因数，都需要以报告会的方式提供，并在提交架构小组审批时，提交这部分文档。
- 在项目组成员一致认可该开发包的引入后，提交架构小组审批并备案后，允许新增。
审批流程
对于第三方开发包的调整，需要提出人、项目组、架构组三方面的共同确认，其审批流程如下：
