| [ee4j-pmc] Specification Projects and the Jakarta Namespace |
TL;DR
As has been noted in past postings to the PMC mailing list, several of the EE4J Projects are going through the transformation to becoming Specification Projects. To that end, these Specification Projects will be following the Jakarta EE Specification Process, which is a slight derivative of the Eclipse Foundation Specification Process. Until this transformation is complete for your API project, it is advised to not perform additional “official” Github releases. Milestone or Release Candidate or Alpha/Beta releases are fine -- just not “Major.Minor” releases.
Reasoning...
The Jakarta EE Specification Process outlines the Release Process for Specifications and the associated APIs and TCKs. There is a clear distinction between the Github development releases and the official, “ratified” releases. This process is required in order to ensure proper IP flow from the Specification Project to the corresponding implementers of said Specifications. Implementing against a Github release of an API does not protect the IP grants.
During the process of ratifying a Specification release, the corresponding Github release is presented as a read-only snapshot of the proposal. Thus, no additional development is allowed during this Specification release process. Once the Specification release is approved by the Specification Committee, then the Github release artifacts will be moved to a proper repository and be made available under the Eclipse Foundation Specification License. This Specification version is the one to be used by implementers.
Additional Reasoning…
As many of you know, there is also a lively discussion on the Platform-Dev mailing list about the move from the javax namespace to the jakarta namespace -- whether we should do this incrementally or all-at-once (big bang). Until that discussion commences and a decision/direction has been determined, projects should not be expending effort on making any type of jakarta namespace changes. For example, if an incremental approach is decided, then not every project will be requiring these namespace updates.