efsp/content/diff_v1.3.html

<div id="preamble">
<div class="sectionbody">
<div class="paragraph">
<p>Version 1.<del data-operation-index="1">2. Effective June 30, 2019</del><ins data-operation-index="1">3. DRAFT</ins></p>
</div>
<div id="toc" class="toc">
<div id="toctitle" class="title">Table of Contents</div>
<ul class="sectlevel1">
<li>Applicable Documents and Processes</li>
<li>Terms and Definitions</li>
<li>Structure and Organization
<ul class="sectlevel2">
<li>Specification Projects</li>
<li>Specifications</li>
<li>Committers</li>
<li>Specification Committee</li>
<li>Release Plans</li>
</ul>
</li>
<li>Specification Process
<ul class="sectlevel2">
<li>Specification Project Lifecycle</li>
<li>Specification Version Lifecycle</li>
<li>Reviews</li>
<li>Ratification</li>
</ul>
</li>
<li>Exceptions</li>
<li>Addendum: Process Revisions
<ul class="sectlevel2">
<li>Eclipse Development Process</li>
<li>Eclipse Foundation Specification Process</li>
<li>Working Group Specification Process</li>
</ul>
</li>
<li>History
<ul class="sectlevel2">
<li>ChangeLog</li>
</ul>
</li>
</ul>
</div>
<div class="paragraph">
<p>The document describes the Eclipse Foundation Specification Process (EFSP) for optional use by Eclipse Foundation Working Groups.</p>
</div>
<div class="paragraph">
<p><del data-operation-index="3">The EFSP leverages and augments the Eclipse Development Process (EDP). The EDP defines important concepts, including the Open Source Rules of Engagement, the organizational framework for open source projects and teams, releases, reviews, and more.</del></p></div><div class="paragraph"><p>Although many of the activities related to this process are conducted by open source projects operating under the EDP, this specification process, and the Specification Versions delivered under it, are to be managed by Working Groups.</p>
</div>
<div class="paragraph">
<p>Subject to the approval of the Eclipse Management Organization (Executive Director or Delegate), individual Specification Committees may tailor the process for their unique requirements.</p>
</div>
<div class="paragraph">
<p>This document, and future revisions thereof will be approved by the Eclipse Foundation Board of Directors.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="efsp-documents">Applicable Documents and Processes</h2>
<div class="sectionbody">
<div class="ulist">
<ul>
<li>
<p>Eclipse Foundation Bylaws</p>
</li>
<li>
<p><ins data-operation-index="5">Eclipse Foundation </ins>Working Group Process</p>
</li>
<li>
<p><ins data-operation-index="7">The </ins>Working Group Participation Agreement<ins data-operation-index="9"> for the corresponding Working Group</ins></p>
</li>
<li>
<p>Eclipse Foundation Specification License</p>
</li>
<li>
<p>Eclipse Foundation TCK License</p>
</li>
<li>
<p>Eclipse Foundation Trademark License Agreement</p>
</li>
<li>
<p>Eclipse Foundation Membership Agreement</p>
</li>
<li>
<p>Eclipse<ins data-operation-index="11"> Foundation</ins> Development Process</p>
</li>
<li>
<p>Eclipse Foundation Intellectual Property Policy</p>
</li>
<li>
<p>Eclipse Foundation Anti-Trust Policy</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>In the event of any conflict between the terms set forth in this EFSP and the terms of the documents listed above, the terms of those documents shall take precedence.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="efsp-terms">Terms and Definitions</h2>
<div class="sectionbody">
<div class="dlist glossary">
<dl>
<dt>Brand </dt>
<dd>
<p>The name and logo selected by the Working Group solely for the use of Compatible Implementations of Specifications designated by a Specification Committee.</p>
</dd>
<dt>Check Point Reviews </dt>
<dd>
<p>The Plan Review, the Progress Review, and the Release Reviews.</p>
</dd>
<dt>Committer </dt>
<dd>
<p>A developer who has the necessary rights to make decisions regarding a Project.</p>
</dd>
<dt>Compatible Implementation </dt>
<dd>
<p>Any implementation that fulfills all requirements of a Final Specification as demonstrated by fulfilling all requirements of the associated TCK.</p>
</dd>
<dt>Contribution </dt>
<dd>
<p>Content delivered to a Project under the terms of the Eclipse Contributor Agreement.</p>
</dd>
<dt>Contributor </dt>
<dd>
<p>An individual who is a party to the Eclipse Contributor Agreement.</p>
</dd>
<dt>Creation Review </dt>
<dd>
<p>A review to assess the community and membership response to a Project Proposal, verifies that appropriate resources are available for the project to achieve its plan, and serves as a Committer election for the project&#8217;s initial Committers. For a complete definition, see the EDP.</p>
</dd>
<dt>Final Specification </dt>
<dd>
<p>A Ratified Specification Version.</p>
</dd>
<dt>Individual Participant </dt>
<dd>
<p>An individual Committer on a Specification Project.</p>
</dd>
<dt>Major Release </dt>
<dd>
<p>A type of Release that includes either significant new functionality and/or breaking changes.</p>
</dd>
<dt>Member Participant </dt>
<dd>
<p>A <ins data-operation-index="13">Strategic or Contributing </ins>Member of the Eclipse Foundation<del data-operation-index="15"> including Solutions Member, Enterprise Member, or Strategic Member</del> (as defined in the Eclipse Foundation Bylaws) that has <del data-operation-index="17">one or</del><ins data-operation-index="17">executed the corresponding Working Group Participation Agreement (for</ins> more <del data-operation-index="19">Committers on a Specification Project.</del><ins data-operation-index="19">information, see the Member Roles and Agreements in the Eclipse Foundation Working Group Process).</ins></p>
</dd>
<dt>Milestone Build </dt>
<dd>
<p>A build of the project content for limited distribution to demonstrate progress and solicit feedback.</p>
</dd>
<dt>Minor Release </dt>
<dd>
<p>A type of Release that includes new features over a Major Release.</p>
</dd>
<dt>Open Source License </dt>
<dd>
<p>One of the following OSI-approved open source licenses:</p>
<div class="sidebarblock">
<div class="content">
<div class="ulist">
<ul>
<li>
<p>Eclipse Public License - v 2.0 (possibly with Secondary Licenses)<br/>
SPDX short identifier: EPL-2.0</p>
</li>
<li>
<p>Eclipse Distribution License - v 1.0<br/>
SPDX short identifier: BSD-3-Clause</p>
</li>
<li>
<p>Apache License - v 2.0<br/>
SPDX short identifier: Apache-2.0</p>
</li>
</ul>
</div>
</div>
</div>
<div class="paragraph">
<p>This list may be modified with the unanimous approval of the Working Group Steering Committee and the Eclipse Foundation Board of Directors.</p>
</div>
</dd>
<dt>Participant </dt>
<dd>
<p>A Member Participant or Individual Participant.</p>
</dd>
<dt>Participant Representative </dt>
<dd>
<p>The Committer on a Specification Project who has the right to represent the interests (including without limitation the right to vote on behalf of) of a Participant. The Participant Representative of an Individual Participant is the same person.</p>
</dd>
<dt><ins data-operation-index="21">Patent License </ins></dt><dd data-diff-node="ins" data-operation-index="21"><p data-diff-node="ins" data-operation-index="21"><ins data-operation-index="21">The Patent License that defines how patent grants flow from a Final Specification to an implementer of the specification. The Patent License is either the Implementation Patent License or Compatible Patent License as defined in the Eclipse Foundation IP Policy.</ins></p></dd><dt>Plan Review </dt>
<dd>
<p>A Review to approve a Release Plan to start a Release Cycle.</p>
</dd>
<dt>Pre-Proposal Phase </dt>
<dd>
<p>A phase in the Project lifecycle during which an individual or group of individuals declares their interest in, and rationale for, establishing a Project and assembles a proposal to create a new Specification Project. For a complete definition, see the EDP.</p>
</dd>
<dt>Profile </dt>
<dd>
<p>A Specification that includes by reference a collection of Specifications and possibly additional requirements.</p>
</dd>
<dt>Progress Review </dt>
<dd>
<p>A type of Review that is used by a Project Team to summarize the accomplishments of the Project, verify that the Eclipse <ins data-operation-index="23">Foundation </ins>Development Process and<ins data-operation-index="25"> Eclipse Foundation</ins> IP Policy have been followed, and to highlight any remaining quality and/or architectural issues. For a complete definition, see the EDP.</p>
</dd>
<dt>Project </dt>
<dd>
<p>A Project is the main operational unit by which all open source development occurs. For a complete definition, see the EDP.</p>
</dd>
<dt>Project Management Committee (PMC) </dt>
<dd>
<p>The primary leadership of a Top-Level Project with  responsibility to ensure that the Projects within its purview are active and viable. For a complete definition, see the EDP.</p>
</dd>
<dt>Project Proposal </dt>
<dd>
<p>A document that describes the Project and the context in which the Project is being created. For more information, see the EDP.</p>
</dd>
<dt>Project Leadership Chain </dt>
<dd>
<p>The leadership chain for a project is composed of the project&#8217;s project lead(s), the leadership of the parent project (if any), the PMC leads and PMC members for the Top-Level Project, the EMO, and the EMO(ED). For a complete definition, see the EDP.</p>
</dd>
<dt>Proposal Phase </dt>
<dd>
<p>A phase in the Project lifecycle during which a Project Proposal is presented to the community and Membership at Large to solicit feedback. For a complete definition, see the EDP.</p>
</dd>
<dt>Ratified </dt>
<dd>
<p>A Specification Version that has been adopted by the Specification Committee and made available under the Eclipse Foundation Specification License to enable the creation and certification of Compatible Implementations.</p>
</dd>
<dt>Release </dt>
<dd>
<p>A Specification Version intended for ratification as a Final Specification.</p>
</dd>
<dt>Release Candidate </dt>
<dd>
<p>A feature-complete Milestone Build.</p>
</dd>
<dt>Release Cycle </dt>
<dd>
<p>The cycle of development that produces a Specification Version.</p>
</dd>
<dt>Release Plan </dt>
<dd>
<p>The description of activities to be undertaken as part of a Release Cycle to produce a Specification Version.</p>
</dd>
<dt>Release Review </dt>
<dd>
<p>A Release Review is a type of Progress Review that is aligned directly with a specific Release. This definition is the same as in the EDP.</p>
</dd>
<dt>Review </dt>
<dd>
<p>The EFSP uses the same reviews as defined in the EDP.</p>
</dd>
<dt>Scope </dt>
<dd>
<p>The defined scope of activities for a Specification Project.</p>
</dd>
<dt>Service Release </dt>
<dd>
<p>A Release that includes only minor changes and/or clarifications over a Major or Minor Release.</p>
</dd>
<dt>Specification </dt>
<dd>
<p>A collection of Application Programming Interface (API) definitions, descriptions of semantic behavior, data formats, protocols, and/or other referenced specifications, along with its TCK, intended to enable the development and testing of independent Compatible Implementations.</p>
</dd>
<dt>Specification Committee </dt>
<dd>
<p>A committee of a Working Group established to manage this Process for technologies within the scope of its Working Group.</p>
</dd>
<dt>Specification Document </dt>
<dd>
<p>The document that defines a Specification.</p>
</dd>
<dt>Specification Project </dt>
<dd>
<p>An Eclipse Foundation Project operating under the EDP and EFSP that is constituted to deliver Specification Versions.</p>
</dd>
<dt>Specification Team </dt>
<dd>
<p>The collective of Committers with responsibilities and privileges on a specific Specification Project.</p>
</dd>
<dt>Specification Version </dt>
<dd>
<p>A specific version of a Specification.</p>
</dd>
<dt>Super-majority </dt>
<dd>
<p>Two-thirds of the eligible voters.</p>
</dd>
<dt>Top-Level Project </dt>
<dd>
<p>An organizational unit that defines an overall mission and scope for a collection of Projects (and Specification Projects). For a complete definition, see the EDP.</p>
</dd>
<dt>Technology Compatibility Kit (TCK) </dt>
<dd>
<p>Software and documented requirements that support the testing of implementations to ensure that they are compatible with the Specification.</p>
</dd>
<dt>Termination of Participation </dt>
<dd>
<p>Occurs when an Individual Participant or Member Participant removes themselves or the Committers in their employ from a Specification Project.</p>
</dd>
<dt>Working Group </dt>
<dd>
<p>An Eclipse Foundation Working Group established under the Eclipse <del data-operation-index="27">Industry</del><ins data-operation-index="27">Foundation</ins> Working Group Process. Definitions from the Working Group Process are included herein by reference.</p>
</dd>
</dl>
</div>
<div class="paragraph">
<p>Other terms used in this document are defined in the EDP.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="efsp-structure">Structure and Organization</h2>
<div class="sectionbody">
<div class="paragraph">
<p>A Specification Project is the main operational unit for Specification development at the Eclipse Foundation.</p>
</div>
<div class="sect2">
<h3 id="efsp-projects">Specification Projects</h3>
<div class="paragraph">
<p>Specification Projects operate under the supervision of both the Project Leadership Chain and the Specification Committee.</p>
</div>
<div class="paragraph">
<p><del data-operation-index="29">Among other things,</del><ins data-operation-index="29">At</ins> the<ins data-operation-index="31"> time of creation, a Specification Project must provide a well-define scope that is bounded by the Scope of its Top-Level Project. The</ins> Scope of a Specification Project is intended to inform companies and individuals so they can determine whether or not to contribute to the <del data-operation-index="33">Specification.</del><ins data-operation-index="33">Specification Project.</ins> Since a change in Scope may change the nature of the contribution to the project, a change to a Specification Project’s Scope must be approved by a Super-majority of the Specification Committee.</p>
</div>
<div class="paragraph" data-diff-node="ins" data-operation-index="35"><p data-diff-node="ins" data-operation-index="35"><ins data-operation-index="35">At the time of creation, a Specification Project must explicitly state whether it utilizes an Implementation Patent License or a Compatible Patent License as defined in the Eclipse Foundation Intellectual Property Policy. The Patent License that defines how patent grants flow from a Final Specification to an implementer of the specification. The choice of Patent License must be made known to the Specification Committee in advance of the initiation of the Ballot to create the Specification Project.</ins></p></div><div class="admonitionblock tip" data-diff-node="ins" data-operation-index="35"><table data-diff-node="ins" data-operation-index="35"><tr data-diff-node="ins" data-operation-index="35"><td class="icon" data-diff-node="ins" data-operation-index="35"><i class="fa icon-tip" title="Tip" data-diff-node="ins" data-operation-index="35"></i></td><td class="content" data-diff-node="ins" data-operation-index="35"><div class="paragraph" data-diff-node="ins" data-operation-index="35"><p data-diff-node="ins" data-operation-index="35"><ins data-operation-index="35">For help regarding selection of a Patent License, see Patents and Specifications.</ins></p></div></td></tr></table></div><div class="paragraph" data-diff-node="ins" data-operation-index="35"><p data-diff-node="ins" data-operation-index="35"><ins data-operation-index="35">A new Specification Project may be created via Project Proposal and Creation Review; alternatively, an existing Project may be converted into a Specification Project via Restructuring Review.</ins></p></div><div class="admonitionblock tip" data-diff-node="ins" data-operation-index="35"><table data-diff-node="ins" data-operation-index="35"><tr data-diff-node="ins" data-operation-index="35"><td class="icon" data-diff-node="ins" data-operation-index="35"><i class="fa icon-tip" title="Tip" data-diff-node="ins" data-operation-index="35"></i></td><td class="content" data-diff-node="ins" data-operation-index="35"><div class="paragraph" data-diff-node="ins" data-operation-index="35"><p data-diff-node="ins" data-operation-index="35"><ins data-operation-index="35">For more information regarding Project creation, see Starting an Open Source Project at the Eclipse Foundation.</ins></p></div></td></tr></table></div></div>
<div class="sect2">
<h3 id="efsp-specifications">Specifications</h3>
<div class="paragraph">
<p>Specifications must be developed by Specification Projects. </p></div><div class="paragraph"><p><del data-operation-index="37">A Specification may describe parts as being optional. Optional parts of a Specification must not conflict with one another; it must be possible for a Compatible Implementation to implement all optional parts.</del></p>
</div>
<div class="paragraph">
<p>A Specification can define rules. If defined, such rules must not override the rules defined in any referenced Specification.</p>
</div>
<div class="paragraph">
<p>A Specification that aggregates other Specifications by reference may be designated as a Profile. Profiles do not have to be arranged in unique subsets (i.e. a Specification may appear in more than one Profile). A <del data-operation-index="39">Super-majority, including a</del><ins data-operation-index="39">successful</ins> Super-majority <ins data-operation-index="41">ballot </ins>of the <del data-operation-index="43">Strategic Members of the Working Group,</del><ins data-operation-index="43">Specification Committee</ins> is required to approve<ins data-operation-index="45"> designation of</ins> a Profile Specification. A Specification Committee may, at its discretion, elect to label one or more Profiles as a <del data-operation-index="47">“Platform”.</del><ins data-operation-index="47">Platform.</ins></p>
</div>
<div class="sect3">
<h4 id="efsp-versions">Specification Versions</h4>
<div class="paragraph">
<p>Each Specification Version references specific versions of its constituent artifacts. These artifacts include the Specification Documents, zero or more other Specifications, one or more Compatible Implementations licensed under an Open Source License, and exactly one associated TCK for this Specification.</p>
</div>
<div class="imageblock">
<div class="content">

</div>
<div class="title">Conceptual structure of a Specification Version</div>
</div>
<div class="paragraph">
<p>The Specification Document and related technical artifacts must be developed by the Specification Team.</p>
</div>
</div>
<div class="sect3">
<h4 id="efsp-tck">Technology Compatibility Kits</h4>
<div class="paragraph">
<p>There is exactly one TCK under an Open Source License for each Specification Version.</p>
</div>
<div class="paragraph">
<p>A specific version of a TCK is chosen by the Specification Project for each Specification Version; the TCK may be different for different Specification Versions.</p>
</div>
<div class="paragraph">
<p>Any implementation that fulfills all of the requirements of the TCK associated with a Final Specification may claim that it is a Compatible Implementation of that Final Specification. The TCK version associated with the Final Specification must not be modified other than as allowed or required by the rules of the TCK.</p>
</div>
<div class="paragraph" data-diff-node="del" data-operation-index="49"><p data-diff-node="del" data-operation-index="49"><del data-operation-index="49">All parts of a Specification, including optional parts, should be covered by the TCK.</del></p></div></div>
<div class="sect3">
<h4 id="efsp-compatible">Compatible Implementations</h4>
<div class="paragraph">
<p>A Compatible Implementation must <del data-operation-index="51">fully implement</del><ins data-operation-index="51">fulfill</ins> all <del data-operation-index="53">non-optional elements</del><ins data-operation-index="53">requirements</ins> of a <ins data-operation-index="55">Final </ins>Specification <del data-operation-index="57">Version, must not extend the API (no supersetting), and must fulfill</del><ins data-operation-index="57">including</ins> all<del data-operation-index="59"> the</del> requirements of the corresponding TCK. A Specification Version must identify at least one Compatible Implementation under an Open Source License that <del data-operation-index="61">implements all optional elements of the Specification and </del>fulfills the requirements<del data-operation-index="63"> of all elements (including optional elements)</del> of the TCK.</p>
</div>
</div>
</div>
<div class="sect2">
<h3 id="efsp-committers">Committers</h3>
<div class="paragraph">
<p>Specification Project Committers must be Members of the Eclipse Foundation. Committers may be Members by virtue of working for a member organization, or may choose to complete the membership process independently.</p>
</div>
<div class="paragraph">
<p>All Specification Project Committers must be covered by a Working Group Participation Agreement.</p>
</div>
<div class="paragraph">
<p>Member Participants have the right to appoint a Participant Representative to every Specification Project that falls under the purview of the Specification Committee.</p>
</div>
</div>
<div class="sect2">
<h3 id="efsp-committee">Specification Committee</h3>
<div class="paragraph">
<p>The Specification Committee works with the PMC to manage the overall vision for the Specification Projects under their supervision.</p>
</div>
<div class="sect3">
<h4 id="efsp-committee-approvals">Approvals</h4>
<div class="paragraph">
<p>A Specification Committee must approve, by Super-majority, the following lifecycle events of Specification Projects:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>The creation of a new Specification Project;</p>
</li>
<li>
<p>The Release Plan for a new Release Cycle of a Specification;</p>
</li>
<li>
<p>Each revision to the Scope of a Specification;</p>
</li>
<li>
<p>Each <ins data-operation-index="65">Check Point </ins>Review of a Specification Project, including the adoption of Specification Versions;</p>
</li>
<li>
<p><del data-operation-index="67">A Profile</del><ins data-operation-index="67">Designation of a</ins> Specification <del data-operation-index="69">(this Super-majority must include</del><ins data-operation-index="69">as</ins> a <del data-operation-index="71">Super-majority of Strategic Members of the Working Group);</del></p></li><li><p><del data-operation-index="71">A Platform designation (this Super-majority must include a Super-majority of Strategic Members of the Working Group);</del><ins data-operation-index="71">Profile;</ins> and</p>
</li>
<li>
<p><del data-operation-index="73">Service Releases.</del><ins data-operation-index="73">Designation of a Profile as a Platform.</ins></p>
</li>
</ul>
</div>
<div class="paragraph">
<p>A ballot is used to seek Specification Committee approval. Unless otherwise stated in this process (or a Working Group-specific derivative of this process), the default period for all Specification Committee ballots is seven (7) days. During that time, any member of a Specification Committee may request that the period be extended to thirty (30) days.</p>
</div>
<div class="paragraph">
<p>A Specification Committee may opt to increase the length of the ballot period, but may not&#8212;&#8203;under any circumstances&#8212;&#8203;reduce any review period to fewer than seven (7) days.</p>
</div>
<div class="paragraph">
<p>All artifacts related to a ballot must be delivered in distribution form to the Specification Committee prior to the start of the ballot period, must not change during the ballot period (with the exception of minor corrections that do not change the semantic intent, as determined by the Specification Committee), and must persist in the delivered form following the ballot as part of the public record.</p>
</div>
</div>
</div>
<div class="sect2">
<h3 id="efsp-plans">Release Plans</h3>
<div class="paragraph">
<p>A Release Plan lists themes and areas of focus, describes Milestone Builds, and lists tentative dates for Reviews. The work defined by a Release Plan must be within the Scope of the Specification Project.</p>
</div>
<div class="paragraph">
<p>The exact requirements for a Release Plan, including the number and timing of Milestone Builds and Reviews, are determined by the Project Leadership Chain and the Specification Committee. Minimally, a Release Plan must include a textual description of the activities planned for the Specification Version, and tentative dates for Milestone Builds, Progress Reviews, and the Release Review. Following approval, the Specification Committee must be notified of any changes to the dates of the Progress Review and the Release Review. The Specification Committee may, at their discretion, demand that the project team engage in additional Progress Reviews.</p>
</div>
<div class="paragraph">
<p>The Project Proposal serves as the Release Plan for the first release of a Specification Project.</p>
</div>
<div class="paragraph">
<p>A Release Plan must be approved by a Super-majority of the Specification Committee. If the Release Plan is rejected, the Specification Team may reapply at a future date.</p>
</div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="efsp-process">Specification Process</h2>
<div class="sectionbody">
<div class="paragraph">
<p>The EFSP is based on the Development Process described in the EDP.</p>
</div>
<div class="sect2">
<h3 id="efsp-project-lifecycle">Specification Project Lifecycle</h3>
<div class="paragraph">
<p>The Specification Project Lifecycle is defined by the EDP.</p>
</div>
<div class="sect3">
<h4 id="efsp-releases">Releases</h4>
<div class="paragraph">
<p>While in the Incubation and Mature Phases, a Specification Project may engage in the Release process to produce Specification Versions which, when Ratified, become Final Specifications. Reviews are required for all Releases of a Specification Project.</p>
</div>
<div class="paragraph">
<p>There are three types of Releases: Major, Minor, and Service. A Specification Team may consult with their PMC and Specification Committee to determine the appropriate classification.</p>
</div>
<div class="admonitionblock note">
<table>
<tr>
<td class="icon">
<i class="fa icon-note" title="Note"></i>
</td>
<td class="content">
<div class="paragraph">
<p>The notions of Major, Minor, and Service Release bear a close resemblance to the "MAJOR.MINOR.PATCH" structure described by the Semantic Versioning specification. While a Specification Team may opt to use Semantic Versioning when naming their releases, this process imposes no requirement to do so. Further, this process imposes no requirement to tie any particular type of Release to any particular Semantic Versioning scheme.</p>
</div>
</td>
</tr>
</table>
</div>
</div>
<div class="sect3">
<h4 id="efsp-releases-major">Major and Minor Releases</h4>
<div class="paragraph">
<p>A Major Release includes significant new features and/or breaking changes. A Minor Release includes new features over a Major Release.</p>
</div>
<div class="paragraph">
<p>A Specification Project&#8217;s first Release must be a Major or Minor Release.</p>
</div>
</div>
<div class="sect3">
<h4 id="efsp-milestones">Milestone Builds</h4>
<div class="paragraph">
<p>Leading up to a Release, a Specification Team must produce at least one Milestone Build. <del data-operation-index="75">Milestone</del><ins data-operation-index="75">Milestones</ins> Builds <del data-operation-index="77">and Release Candidates are "almost Releases" intended</del><ins data-operation-index="77">should be staged</ins> for <del data-operation-index="79">adoption and testing by early-adopters.</del><ins data-operation-index="79">limited distribution to key stakeholders to solicit feedback.</ins> No formal Reviews are required for Milestone Builds.</p>
</div>
<div class="paragraph">
<p>Under no circumstances are Milestone Builds to be used as a substitute for doing proper official Releases.</p>
</div>
<div class="paragraph">
<p>All communication regarding Milestone Builds must include caveats explaining that these are not official Releases. Milestone Builds and Release Candidate builds must be labeled as such (e.g. <code>x.yMn</code>, <code>x.yRCn</code>, <code>alpha</code>, <code>beta</code>, or similar).</p>
</div>
</div>
<div class="sect3">
<h4 id="efsp-releases-service">Service Releases</h4>
<div class="paragraph">
<p>A Service Release includes only minor changes and/or clarifications over a Major or Minor Release. Specifically, a Service Release must not include any significant new features and/or breaking changes. A Specification Team may consult with their PMC and Specification Committee to determine precisely what constitutes a minor change and/or clarification.</p>
</div>
<div class="paragraph">
<p>A Specification Team must have engaged in a successful Release Review <del data-operation-index="81">for a Major or Minor Release </del>prior to engaging in a Service Release.</p></div><div class="admonitionblock note" data-diff-node="ins" data-operation-index="83"><table data-diff-node="ins" data-operation-index="83"><tr data-diff-node="ins" data-operation-index="83"><td class="icon" data-diff-node="ins" data-operation-index="83"><i class="fa icon-note" title="Note" data-diff-node="ins" data-operation-index="83"></i></td><td class="content" data-diff-node="ins" data-operation-index="83"><div class="paragraph" data-diff-node="ins" data-operation-index="83"><p data-diff-node="ins" data-operation-index="83"><ins data-operation-index="83">In the case where a Specification Project hosts multiple Specifications, the first release any individual Specification must be treated as either a Major or Minor Release regardless of its history.</ins></p></div></td></tr></table></div><div class="paragraph"><p>No <del data-operation-index="85">Progress Review is</del><ins data-operation-index="85">reviews are</ins> required for a Service <del data-operation-index="87">Release; the Specification Team must, however, engage in a successful Release Review.</del><ins data-operation-index="87">Release.</ins></p>
</div>
</div>
</div>
<div class="sect2">
<h3 id="efsp-version-lifecycle">Specification Version Lifecycle</h3>
<div class="paragraph">
<p>To produce a Specification Version (with the exception of Service Releases) a Specification Team must engage in a formal Release Cycle under the supervision of the Project Management Committee (PMC) and the Specification Committee.</p>
</div>
<div class="imageblock">
<div class="content">

</div>
<div class="title">An overview of the Eclipse Foundation Specification Process</div>
</div>
<div class="paragraph">
<p>A Specification Project’s first Release Cycle starts with the successful completion of a Creation <del data-operation-index="89">Review.</del><ins data-operation-index="89">Review (or Restructuring Review in the event that a Restructuring Review is used to convert an existing Project into a Specification Project).</ins> To start a subsequent Release Cycle (and every Release Cycle thereafter), the Specification Team must present a Release Plan to the Specification Committee in a Plan Review. The Plan Review must be approved by a Super-majority of the Specification Committee.</p>
</div>
<div class="paragraph">
<p>A Release Cycle ends when the Specification Team delivers a Specification Version to the EMO and Specification Committee via a Release Review. To extend the Release Cycle, the Specification Team must stage a Milestone Build and engage in a Progress Review. The Specification Team must engage in either a Release Review (which ends the Release Cycle) or a Progress Review (which extends the Release Cycle) within twelve (12) months of the last Review.</p>
</div>
<div class="paragraph">
<p>The Specification Team must deliver at least one Milestone Build to demonstrate progress and solicit feedback. Milestone Builds may be incomplete (for example, designated Compatible Implementations will not necessarily pass Milestone Builds of the TCK in their entirety). Subsequent Milestone Builds should, however, demonstrate progress. Later (feature complete) Milestone Builds may be referred to as Release Candidates.<del data-operation-index="91"> Milestones Builds should be staged for limited distribution to key stakeholders to solicit feedback.</del></p>
</div>
<div class="paragraph">
<p>The Specification Team must engage in a successful Release Review before the final Specification Version may be Ratified. A Specification Version becomes a Final Specification when it is Ratified.</p>
</div>
</div>
<div class="sect2">
<h3 id="efsp-reviews">Reviews</h3>
<div class="paragraph">
<p>Reviews are a formal process through which all major lifecycle events and changes to Specification Projects are announced and reviewed by the membership-at-large, and approved by the PMC, the Specification Committee, and the EMO.</p>
</div>
<div class="paragraph">
<p>A Specification Project may engage in all of the Reviews described by the EDP with the additional requirement that approval by a Super-majority of the Specification Committee is required to successfully complete a Review. Such Review shall include affirmation that the Specification Version in progress remains within the Scope of the Specification Project. Other additions and qualifications are noted in the descriptions of the reviews below.</p>
</div>
<div class="paragraph">
<p>Project Leads are responsible for initiating the appropriate Reviews. The Project Leadership Chain may also initiate a Review on the project’s behalf.</p>
</div>
<div class="paragraph">
<p>The Specification Team must complete all required due diligence under the Eclipse <ins data-operation-index="93">Foundation </ins>IP Policy before initiating a Review.</p>
</div>
<div class="sect3">
<h4 id="efsp-reviews-creation">Creation Review</h4>
<div class="paragraph">
<p>Specification Projects are created using the process defined by the EDP with the added requirement that the Specification Committee must approve the Project Proposal by a Super-majority before the Specification Project can successfully complete a Creation Review.</p>
</div>
<div class="paragraph">
<p><ins data-operation-index="95">An existing Project may be converted into a Specification Project via a Restructuring Review. In this case, the Restructuring Review serves as the Creation Review; other changes to the nature of the existing Project (e.g., the Scope) may be included with the Restructuring Review. Unlike a Creation Review, no Project Proposal is required for a Restructuring Review. Like a Creation Review, a Restructuring Review that converts an existing Project into a Specification Project must be approved by the Specification Committee by Super-majority ballot.</ins></p></div><div class="paragraph"><p>The Specification Committee ballot and the <del data-operation-index="97">Creation Review</del><ins data-operation-index="97">review</ins> may run in parallel.<del data-operation-index="99"> The Project Proposal text must not be changed during the Creation Review period. If changes are required during this period, the Project Proposal is pushed back into the Proposal Phase.</del></p>
</div>
</div>
<div class="sect3">
<h4 id="efsp-reviews-plan">Plan Review</h4>
<div class="paragraph">
<p>A Plan Review provides a means for the Specification Team to present their Release Plan to the Project Leadership Chain, the Specification Committee, and the community for feedback. The Specification Committee must approve the Plan Review by a Super-majority ballot.</p>
</div>
</div>
<div class="sect3">
<h4 id="efsp-reviews-progress">Progress Review</h4>
<div class="paragraph">
<p>Progress Reviews are used to extend a Release Cycle. During a Release Cycle a Project Team may be required to engage in one or more Progress Reviews.</p>
</div>
<div class="paragraph">
<p>The timing of a Progress Review must coincide with the staging of a Milestone Build which must be delivered to the PMC and the Specification Committee before the start of the Review.</p>
</div>
<div class="paragraph">
<p>The Specification Committee must approve the Progress Review by a Super-majority.</p>
</div>
<div class="paragraph">
<p>Progress Reviews may be combined with a Graduation or Restructuring Review, but must not be combined or overlap with a Release Review.</p>
</div>
</div>
<div class="sect3">
<h4 id="efsp-reviews-release">Release Review</h4>
<div class="paragraph">
<p>A Specification Project must engage in a successful Release Review at the end of each Release Cycle.</p>
</div>
<div class="paragraph">
<p>The final build of the Specification Version’s artifacts must be delivered to the PMC and Specification Committee before the start of the Release Review. The final build may be staged before the start of the review, but must not be distributed as an official release until the Release Review is successfully completed.</p>
</div>
<div class="paragraph">
<p>The Specification Team must provide evidence that the TCK selected for the Specification Version provides sufficient coverage to reasonably validate Compatible Implementations.</p>
</div>
<div class="paragraph">
<p>The Specification Team must provide evidence that cited Compatible Implementations fulfill all requirements of the <del data-operation-index="101">TCK and that at least one Compatible Implementation implements all optional aspects.</del><ins data-operation-index="101">TCK.</ins></p>
</div>
<div class="paragraph">
<p>A Release Review concludes successfully with approval from the PMC and EMO, and approval by a Super-majority of the Specification Committee.</p>
</div>
<div class="paragraph">
<p>With approval, the Specification Project must release the final build of the artifacts of the Specification Version.</p>
</div>
</div>
</div>
<div class="sect2">
<h3 id="efsp-ratification">Ratification</h3>
<div class="paragraph">
<p>With the approval of the Specification Committee by a Super-majority, a Specification Version is Ratified and the associated artifacts can be promoted and distributed by the Specification Committee as a Final Specification.</p>
</div>
<div class="paragraph">
<p>All Specification Versions referenced by a Ratified Final Specification must themselves be Ratified. The Release Review for prerequisite Specification Versions may be run concurrently with the Release Review for a referenced Specification Version.</p>
</div>
<div class="paragraph">
<p>The Specification Document for the Final Specification must be distributed as read-only text under the Eclipse Foundation Specification License. The Ratified TCK in composite must be distributed under the Eclipse Foundation Technology Compatibility Kit License. Other technical artifacts must be distributed under an Open Source License.</p>
</div>
<div class="paragraph">
<p>The diagram below is a conceptual model of the transition from a Specification Version to a Final Specification. No specific packaging technology or structure should be implied from this diagram.</p>
</div>
<div class="imageblock">
<div class="content">

</div>
<div class="title">Conceptual model of the transition from a Specification Version to a Final Specification. Note that no specific packaging technology or structure should be implied from this diagram.</div>
</div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="exceptions">Exceptions</h2>
<div class="sectionbody">
<div class="paragraph">
<p>Exceptions to this process may be granted only with Super-majority approval of the Specification Committee and approval of the Executive Director. All exceptions must be documented as part of the public record. Such documentation must include the exact change to the process, the case or conditions under which it applies, and the votes of each Specification Committee member.</p>
</div>
<div class="paragraph">
<p>Notwithstanding this exception process, no Specification Committee ballot period may be shorter than seven (7) days.</p>
</div>
<div class="paragraph">
<p>This exception process may not be used to override a Specification Committee member&#8217;s request to extend the ballot period.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="efsp-addendum-revisions">Addendum: Process Revisions</h2>
<div class="sectionbody">
<div class="sect2">
<h3 id="efsp-addendum-revisions-edp">Eclipse Development Process</h3>
<div class="ulist">
<ul>
<li>
<p>Architecture Council initiates work, gathers requirements, and authors an updated document.</p>
</li>
<li>
<p>Architecture Council approves final draft by simple majority (lazy consensus).</p>
</li>
<li>
<p>Eclipse Board of Directors approves final draft by super-majority vote</p>
</li>
<li>
<p>Version is published for use.</p>
</li>
</ul>
</div>
</div>
<div class="sect2">
<h3 id="efsp-addendum-revisions-efsp">Eclipse Foundation Specification Process</h3>
<div class="ulist">
<ul>
<li>
<p>Executive Director convenes a committee (composed primarily, but not exclusively, of representatives from Working Group Specification Committees) and appoints a chairperson.</p>
</li>
<li>
<p>Committee initiates work, gathers requirements, and authors an updated document</p>
</li>
<li>
<p>Committee approves final draft by simple majority (lazy consensus).</p>
</li>
<li>
<p>Eclipse Board of Directors approves the final draft.</p>
</li>
<li>
<p>Version is published for use.</p>
</li>
</ul>
</div>
<div class="admonitionblock note" data-diff-node="del" data-operation-index="103"><table data-diff-node="del" data-operation-index="103"><tr data-diff-node="del" data-operation-index="103"><td class="icon" data-diff-node="del" data-operation-index="103"><i class="fa icon-note" title="Note" data-diff-node="del" data-operation-index="103"></i></td><td class="content" data-diff-node="del" data-operation-index="103"><div class="paragraph" data-diff-node="del" data-operation-index="103"><p data-diff-node="del" data-operation-index="103"><del data-operation-index="103">A Board delegation in place for the Executive Director to approve version 1.0 of the EFSP</del></p></div></td></tr></table></div></div>
<div class="sect2">
<h3 id="efsp-addendum-revisions-wg">Working Group Specification Process</h3>
<div class="ulist">
<ul>
<li>
<p>Working Group Specification Committee initiates work, gathers requirements, and authors an updated document.</p>
</li>
<li>
<p>Working Group Specification Committee approves final draft by super-majority vote (as defined in the EFSP)</p>
</li>
<li>
<p>Working Group Steering Committee approves final draft</p>
</li>
<li>
<p>EMO(ED) approves final draft.</p>
</li>
<li>
<p>Version is published for use.</p>
</li>
</ul>
</div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="efsp-history">History</h2>
<div class="sectionbody">
<div class="paragraph">
<p>Changes made in this document:</p>
</div>
<div class="sect2">
<h3 id="changelog">ChangeLog</h3>
<div class="sect3">
<h4 id="version-1-2-2019-06-30">[Version 1.2] - 2019-06-30</h4>
<div class="sect4">
<h5 id="added">Added</h5>
<div class="ulist">
<ul>
<li>
<p>Clarification that all reviews are by default seven (7) days, see https://github.com/EclipseFdn/EFSP/issues/14.</p>
</li>
<li>
<p>A section that describes how exceptions to the process may be granted, see https://github.com/EclipseFdn/EFSP/issues/12.</p>
</li>
</ul>
</div>
</div>
<div class="sect4">
<h5 id="changes">Changes</h5>
<div class="ulist">
<ul>
<li>
<p>Clarified that there must be exactly one TCK (not "TCK project") for each Specification Version.</p>
</li>
<li>
<p>The requirement to engage in Progress Reviews is now time-based, see https://github.com/EclipseFdn/EFSP/issues/13.</p>
</li>
<li>
<p>Reworded parts of the "Specification Version Lifecycle" section.</p>
</li>
<li>
<p>Clarify that a formal Release Cycle is not required for a Service Release.</p>
</li>
<li>
<p>Clarified that a Progress Review must not overlap with a Release Review.</p>
</li>
<li>
<p>Recasted the defined term "Milestone" as "Milestone Build".</p>
</li>
</ul>
</div>
</div>
</div>
<div class="sect3">
<h4 id="version-1-1-2019-03-20">[Version 1.1] - 2019-03-20</h4>
<div class="sect4">
<h5 id="added-2">Added</h5>
<div class="ulist">
<ul>
<li>
<p>Link to the Eclipse Foundation Specification License.</p>
</li>
<li>
<p>Link to the Eclipse Foundation TCK License.</p>
</li>
<li>
<p>Definitions of "Release", "Major Release", and "Minor Release".</p>
</li>
<li>
<p>Service Releases require a Release Review.</p>
</li>
<li>
<p>Specification Committee votes requires a Super-major of members of the Working Group (not members of the Eclipse Foundation).</p>
</li>
<li>
<p>Specification Committee votes must be scheduled to run for a period of no less than one week.</p>
</li>
<li>
<p>All artifacts related to a vote must be delivered in distribution form to the Specification Committee prior to the start of the vote, must not change during the voting period, and must persist in the delivered form following the vote as part of the public record.</p>
</li>
<li>
<p>New section that describes releases.</p>
</li>
</ul>
</div>
</div>
<div class="sect4">
<h5 id="removed">Removed</h5>
<div class="ulist">
<ul>
<li>
<p>The Specification Project creation process diagram (moved to the FAQ).</p>
</li>
</ul>
</div>
</div>
<div class="sect4">
<h5 id="changes-2">Changes</h5>
<div class="ulist">
<ul>
<li>
<p>Simplified the definition of "Service Release".</p>
</li>
<li>
<p>Made the delivery of Final Specifications inclusive of Service Releases.</p>
</li>
<li>
<p>Use the term "ballot" rather than the ambiguous "vote".</p>
</li>
</ul>
</div>
</div>
</div>
</div>
</div>
</div>