GEP-1

GEP 代表 Groovy 增强提案。GEP 是一份文档，为 Groovy 开发团队和用户社区提供关于 Groovy、语言、API、集成或基础设施的新功能、增强或更改的信息。无论何时添加或更改是重要的，并且需要详细讨论其理由、设计或对项目的影响，都应考虑编写 GEP。

GEP 的概念从 Python 的 PEP (Python 增强提案) 中获得灵感。

对于非平凡、复杂或战略性的功能，邮件列表上的讨论很难领导和跟踪，而且通常不能帮助达成共识。编写一份适当的文档来解释所述功能的设计和影响，可以让想法的发起者和整个社区都有机会提供有趣且有用的反馈，并有助于更好地理解该提案的理由、设计决策和影响。

GEP

GEP 的类型可以是以下几种

如果 GEP 是一个功能型 GEP，它还应

GEP 的 "状态" 可以是

除了所有这些元数据，根据需要，GEP 还应

Groovy 增强提案的通用工作流程如下

GEP 的起源通常来自 Groovy 邮件列表上关于新功能或更改的讨论，当 Groovy Despot 和开发团队认为需要适当记录和阐述这个新想法时，以便进一步讨论和分析。一般来说，简单的错误修复和次要增强不需要完整的 GEP。GEP 仅在 Groovy PMC 同意的情况下启动。

Groovy PMC 会分配一个唯一的编号，并为该 GEP 创建一个有意义的 "标题"。如果适用，将提出一个建议的目标 Groovy 版本，用于包含该 GEP。该努力的负责人（通常是 GEP 的发起者或其主要开发人员）负责创建 GEP、编写详细文档提出此增强，并最终为目标 Groovy 版本提供分支（或 PR 或补丁）作为参考实现。一旦开发团队和 "负责人" 对 GEP 的状态感到满意，就应决定是否将 GEP 集成到 Groovy 中，并为该任务创建一个 JIRA 问题。根据 Apache 指南，Groovy PMC 对是否接受 GEP 作为最终状态 GEP 有最终决定权。

一旦在适当的 Groovy 存储库中添加了适当的文档，并且参考实现已达到成熟度，并提供了一个涵盖该功能的良好测试套件，GEP 在 Groovy 中的集成即为最终状态。如果 GEP 未能满足 GEP 流程的所有要求，则可以拒绝或推迟 GEP。