GEP-1

GEP stands for Groovy Enhancement Proposal. A GEP is a document providing information to the Groovy development team and user community describing a new feature, an enhancement, or a change to Groovy, the language, its APIs, its integration, or its infrastructure. Whenever such an addition or change is significant and deserves a detailed discussion on its rationale, its design, or its impact on the project, the writing of a GEP should be considered.

The concept of the GEP was freely inspired from Python’s PEP (Python Enhancement Proposal).

For non-trivial, complex or strategic features, discussions on mailing-lists are difficult to lead and follow, and often don’t help reach a consensus. Writing a proper document explaining the design and implications of said feature allows both the originator of the idea and the community at large to have a chance to provide interesting and useful feedback and helps better understanding the rationale, the design decisions, the impact of the proposal.

A GEP:

The type of a GEP can be of the following:

If the GEP is a Feature GEP, it should also:

The "Status" of a GEP can be:

Beyond all these metadata, as appropriate, a GEP should also:

The general workflow of a Groovy Enhancement Proposal is as follows:

The inception of a GEP generally stems from a discussion on the Groovy mailing-lists about a new feature or change when the Groovy Despot and the development team deem necessary to properly document and articulate this new idea, for further discussion and analysis. Generally, simple bug fixes and minor enhancements don’t require a full-blown GEP. A GEP is started solely with the agreement of the Groovy PMC.

A unique Number is assigned by the Groovy PMC and a meaningful "Title" is created for this GEP. A proposed Target Groovy version is proposed for the inclusion of this GEP if appropriate. A Leader for this effort (usually the instigator of the GEP or the lead developer of it) takes care of the creation of the GEP, of writing a detailed document proposing this enhancement, and eventually of providing a reference implementation as a branch (or PR or patch) for the targeted Groovy version. Once the development team and the "Leader" are happy with the status of the GEP, a decision should be made to act the integration of this GEP into Groovy and a JIRA issue for this task should be created. As per Apache guidelines, the Groovy PMC has the last say on the acceptation of the GEP as a Final status GEP.

The integration of the GEP in Groovy is Final once proper documentation is added to the appropriate Groovy repo and that the reference implementation has reached maturity and provides a good test suite covering the feature. If the GEP doesn’t fulfill all the requirements of the GEP process, the GEP can be rejected or deferred.