Eclipse开源政策系列 – 10 – Eclipse品质(Eclipse Quality)

Eclipse Quality意味着整个社区内开放的、包容的及可预测的过程中开发出的可扩展的框架和示范性的工具。从“消费角度”来看，Eclipse Quality意味着对用户友好（示范性工具-用起来很酷/很爽）并且对插件开发者可用（使用API提供可用的构建基块）。从“创造角度”来看，Eclipse Quality意味着具有透明和开放的过程，无论信仰，开放并欢迎技术领导者参与。

Eclipse Quality不是非黑即白。相反，品质是一个范围，我们期望Eclipse项目会一步步提高它们的品质。Eclipse Quality是贯穿整个项目的持续进化，而且一个项目的品质评估必须与该项目的成熟度级别相适应。例如，一个在孵化阶段的项目将比在成熟阶段的项目多一些临时性API并且少一些的平台级API。同样地，1.0发布版将比2.0发布版少一些API客户端，而3.0发布版将比2.0发布版有一个更好的逐步步的迁移计划，等等。

请注意，Eclipse Quality是关于可扩展性框架和示范性工具二者的——优秀的工具对吸引用户非常重要，用户会再吸引生态系统，生态系统又会提供会员来贡献资源，会员又会创建更多有价值的框架和工具。不管是没有用户的框架还是没有框架的工具都不是软件开发领域中有趣的点。

Eclipse Quality目标

● 平台品质框架（注意“品质框架”在这里指的是高品质API[1]（例如NetBeans的模块API[2]或者Java平台API[3]，再或者Windows API[4]），而不是指Eclipse Platform项目）

● 平台品质工具

● 所有的示范性工具都是构建于平台API之上

● 达到企业级应用的性能和可扩展性

● 可被任何Eclipse开发者使用的自动化测试和质量计划。我们想要让Eclipse的任何用户都可以运行所有测试，以验证他们已正确地安装了可工作的框架和工具。

● 一个版本迁移计划潜在地包含自动转换工具。版本迁移不仅包含API，还包括由工具产生的内容（例如，配置文件、持久层表格等）

● API稳定性

● 可预测的行为和可预测的变化速度

● 已证明的社区参与

● 按照Eclipse知识产权政策和其它Eclipse流程[5][6][7][8]进行知识产权尽职调查（这是唯一要求的Quality要素，其它的都是目标）。

API，临时的或不是

在早先的一个草案文件中，Eclipse Quality API[9]，作为平台级API被定义为拥有以下几点：

● 规范，对封面故事和必要细节的描述。规范应该明确定义了什么和未定义什么。此外，规范应说明哪些部分有可能在将来发生变化（例如，这个有两个值的参数将来可能会有N个值）。规范文档很难于编写，它不仅仅是有关该组件的一两段话。

● 测试套件

● 实现

● 一个或多个客户端。通常来讲，仅有一个客户端是不够的——理想情况下，Eclipse quality的API客户端是由另外的团队开发的。由创建了API实现的同一个团队编写的客户端（API用户）通常都会受到信息泄露的影响，所以这并不是对该API的好的测试。比较好的做法是两个或多个客户端，每一个客户端都由不同的团队开发，团队之间仅通过API文档来交流。

● 支持承诺。有关API将如何在版本之间保持稳定的隐式或显式的承诺。

请注意，API（应用程序接口）是框架的整个公共编程表层，因此，它不仅包含Java类、包和接口，还包括扩展点、文件格式、生成的元数据，甚至包括传递到内部包的对象。

有些代码在将来发布中可能会成为API，但在当前版本的发布中还未达到标准。对这样的代码怎么办的问题，我们可以考虑以下情况：

	规范	测试套件	实现	客户端	支持承诺	包
平台API	是	是	是	是	是	公共的
临时的(Provisional)	是	是	是	是	不太支持	公共的
未完成(Incomplete)	未完成	未完成	是	是	是	公共的
试验性的(Experimental)	是	是	是	是	?	临时的
非API(Non-API)	-	-	是	-	没有支持	内部

Provisional、Incomplete和Experiment API都属于“短暂的API”。Provisional和Incomplete是比较有趣的案例。在本定义下，Provisional API从所有角度（良好的规范、良好的Javadoc、良好的测试等）来看都算是真正API，但是该项目觉得没有足够的社区反馈来完全冻结该API。TPTP项目会在为所有的新API介绍时使用Provisional API：该新API在某个发布版X中会作为Provisional API来发布，并且会在发布版X+1中固定为平台API。

Incomplete API是指项目中那些在定义API之前写的代码，因此文档和测试套件都不完整，但是项目打算支持该API。Incomplete API可能会出现在里程碑发布版中（尽管缺少文档将很难让插件开发者社区来采纳并验证这些API），但是不能出现在正式发布版中。

 

[1] 诚然，对“平台品质工具”还没有一个很好的定义。本文档的未来版本将试图澄清这一点。

本文档由EMO主持编写。