Eclipse Development Process
- 1 Purpose
- 2 Principles
- 3 Requirements
- 4 Project Structure and Organization
- 5 Roadmap Process
- 6 Development Process
- 6.1 Mentors
- 6.2 Project Lifecycle
- 6.2.1 Pre-proposal
- 6.2.2 Proposal
- 6.2.3 Incubation
- 6.2.4 Mature
- 6.2.5 Top-Level
- 6.2.6 Archived
- 6.3 Reviews
- 6.4 Releases
- 6.5 Grievance Handling
- 7 Precedence
- 8 Revisions
The Eclipse technology is a vendor-neutral, open development platform supplying frameworks and exemplary, extensible tools (the 'Eclipse Platform'). Eclipse Platform tools are exemplary in that they verify the utility of the Eclipse frameworks, illustrate the appropriate use of those frameworks, and support the development and maintenance of the Eclipse Platform itself; Eclipse Platform tools are extensible in that their functionality is accessible via documented programmatic interfaces. The purpose of Eclipse Foundation Inc., is to advance the creation, evolution, promotion, and support of the Eclipse Platform and to cultivate both an open source community and an ecosystem of complementary products, capabilities, and services.
|Explanatory comments, guidelines, and checklists - as well as additional requirements added by the EMO per section 3 - are noted in yellow boxes.|
- Principles outlines the basic principles upon which the development process is based.
- Requirements describes the requirements that the Eclipse community has for its development process.
- Structure and Organization specifies the structure and organization of the projects and project community at Eclipse.
- Roadmap Process describes the manner by which the EMO will work with the projects to create the annual Eclipse Roadmap.
- Development Process outlines the lifecycle and processes required of all Eclipse projects.
- Open - Eclipse is open to all; Eclipse provides the same opportunity to all. Everyone participates with the same rules; there are no rules to exclude any potential contributors which include, of course, direct competitors in the marketplace.
- Transparent - Project discussions, minutes, deliberations, project plans, plans for new features, and other artifacts are open, public, and easily accessible.
- Meritocracy - Eclipse is a meritocracy. The more you contribute the more responsibility you will earn. Leadership roles in Eclipse are also merit-based and earned by peer acclaim.
The Eclipse Foundation has the responsibility to ...cultivate...an ecosystem of complementary products, capabilities, and services.... It is therefore a key principle that the Eclipse Development Process ensures that the projects are managed for the benefit of both the open source community and the ecosystem members. To this end, all Eclipse projects are required to:
- communicate their project plans and plans for new features (major and minor) in a timely, open and transparent manner;
- create platform quality frameworks capable of supporting the building of commercial grade products on top of them;
- ship extensible, exemplary tools which help enable a broad community of users; and
- participate in the annual Roadmap process to ensure maximum transparency and bi-directional communication with the ecosystem.
- Contributors and Committers - a thriving, diverse and active community
of developers is the key component of any Eclipse Project. Ideally, this
community should be an open, transparent, inclusive, and diverse community
of Committers and (non-Committer) Contributors. Attracting new Contributors and
Committers to an open source project is time consuming and requires active
recruiting, not just passive "openness". The Project Leadership must make reasonable
efforts to encourage and nurture promising new Contributors.
- Projects must have the diversity goals to ensure diversity of thought and avoiding relying on any one company or organization. At the same time, we acknowledge that enforcing a particular diversity metric is a poor way to achieve these goals; rather we expect the project leadership to help the diversity evolve organically.
- Diversity is a means to an end, not an end in itself, thus diversity goals will differ by project based on the other accomplishments of the project(s).
- Project are required to explain their diversity efforts and accomplishments during Reviews.
- Users - an active and engaged user community is proof-positive that the Project's exemplary tools are useful and needed. Furthermore, a large user community is one of the key factors in creating a viable ecosystem around an Eclipse project, thus encouraging additional open source and commercial organizations to participate. Like all good things, a user community takes time and effort to bring to fruition, but once established is typically self-sustaining.
- Adopters - an active and engaged adopter/plug-in developer community is the only way to prove that an Eclipse project is providing extensible frameworks and extensible tools accessible via documented APIs. Reuse of the frameworks within the companies that are contributing to the project is necessary, but not sufficient to demonstrate an adopter community. Again, creating, encouraging, and nurturing an adopter community outside of the Project's developers takes time, energy, and creativity by the Project Leadership, but is essential to the Project's long-term open source success.
This document imposes requirements and constraints on the operation of the Projects, and it does so on behalf of the larger Eclipse community. It is an explicit goal of the Development Process to provide as much freedom and autonomy to the Projects as possible while ensuring the collective qualities benefit the entire Eclipse community.
Similarly, this document should not place undue constraints on the EMO or the Board that prevent them from governing the process as necessary. We cannot foresee all circumstances and as such should be cautious of being overly prescriptive and/or requiring certain fixed metrics.
The frameworks, tools, projects, processes, community, and even the definition of Quality continues to, and will continue to, evolve. Creating rules or processes that force a static snapshot of any of these is detrimental to the health, growth, and ecosystem impact of Eclipse.
Part of the strength of this document is in what it does not say, and thus opens for community definition through convention, guidelines, and public consultation. A document with too much structure becomes too rigid and prevents the kind of innovation and change we desire for Eclipse. In areas where this document is vague, we expect the Projects and Members to engage the community-at-large to clarify the current norms and expectations.
Required - Certain responsibilities and behaviors are required of participants in Eclipse open source projects. Projects that fail to perform the required behaviors will be terminated by the EMO. In keeping with the Guiding Principles, the number of requirements must be kept to an absolute minimum.
Guideline - Other responsibilities and behaviors are recommended best practices. Collectively, we have learned that Projects are more likely to be successful if the team members and leaders follow these recommendations. Projects are strongly encouraged to follow these recommendations, but will not be penalized by this Process if they do not.
The EMO is not permitted to override or ignore the requirements listed in this document without the express written endorsement of the Board of Directors.
Projects with no child Projects are Operating Projects. Projects with one or more child Projects are Container Projects. The descendants of a Project are the Project itself and transitive closure of its child Projects. The top parent of a Project is the Top-Level Project at the top of the hierarchy.
Projects are the unit entity for:
- Code and Releases
- IP Records
- Community Awareness
As defined by the Eclipse Bylaws - Article VII, the Eclipse Management Organization (EMO) consists of the Foundation staff and the Councils. The term EMO(ED), when discussing an approval process, refers to the subset of the EMO consisting of the Executive Director and whomever he or she may delegate that specific approval authority to.
The set of Committers of a Container Project is the union of all the Committers of the child Projects.
Each Operating Project is the finest grained unit of infrastructure supplied by the Eclipse Foundation. Each Operating Project has a single Unix group of its Committers that provides write-access to the Project's files. Each Operating Project has a single bugzilla component for its bugs. ... The exact infrastructure provided by the Eclipse Foundation varies over time and is defined outside this process document.
While Operating Projects are the finest grained unit of infrastructure, there are no constraints on Projects self governing themselves with finer-grained divisions on labor. For example, if Project A wants to divide its code-based into two modules, A1 and A2, and have separate groups of its Committers work on each module, that's perfectly acceptable. However, if Project A wants to have fine-grained access control for those two groups (i.e., separate unix groups), then Project A will need to become a Container Project and create two new Sub-Projects, A.A1 and A.A2, as Operating Projects. That division will require a Creation+Move Review.
Container Projects do not have file infrastructure: no Unix group and no repository.
Any Project in the Mature Phase may make a Release. A Project in the Incubation Phase with two Mentors may make a Release. A Release may include the code from any subset of the Project's descendants. However, if any code is included from an Operating Project, all the code from that Project must be included. In other words, an Operating Project is the level of granularity of code.
All Projects must make the communication channels easy to find. Container Projects are further required to make the separate communication channels of their child Projects (if any) easy to find.
Any Project in the Incubation Phase must correctly identify its website and Releases. A Container Project with at least one descendant Project in Incubation Phase must correctly annotate its own website so as to notify the Eclipse community that incubating Projects exist in its hierarchy. Any Release containing code from an Incubation Phase project must be correctly labeled, i.e., the Incubation Phase is viral and expands to cover all Releases in which it is included.
Sub-Projects do not have separate Charters; Sub-Projects operate under the Charter of their parent Top-Level Project.
All Projects have a defined Scope and all initiatives within that Project are required to reside within that Scope. Initiatives and code that is found to be outside the Scope of a Project may result in the termination of the Project. The Scope of Top-Level Projects is part of the Charter, as approved by the Board of Directors of the Eclipse Foundation.
The Scope of a Sub-Project is defined by the initial project proposal as reviewed and approved by the Project Management Committee (PMC) (as further defined below) of the Project's Project's top parent and by the EMO. A Project's Scope must be a subset of its parent's Scope.
Top-Level Projects are managed by a Project Management Committee (PMC). Sub-Projects are managed by one or more Project Leaders. The PMC Lead(s) of a Top-Level Project are the Project Leader(s) of that project.
PMC Leads are approved by the Board; PMC members and Project Leads are approved by the EMO(ED). The initial Project Leadership is appointed and approved in the Creation Review. Subsequently, additional Project Leadership (PMC members or Sub-Project Leaders) must be elected by the Project's Committers1 and the Board or EMO(ED) (for PMC members and Sub-Project Leads respectively). In the unlikely event that a member of the Project Leadership becomes disruptive to the process or ceases to contribute for an extended period, the member may be removed by (a) if there are at least two other Project Leaders, then unanimous vote of the remaining Project Leadership; or (b) unanimous vote of the Project Leadership of the parent Project.
1Until such time as the Foundation portal supports Project Leader elections, an election held on the Project's developer mailing list will suffice.
Each Project's leadership is required to:
- ensure that the Project is operating effectively by guiding the Project's overall direction and by removing obstacles, solving problems, and resolving conflicts
- operate using open source rules of engagement: meritocracy, transparency, and open participation.
- ensure that the projects and its sub-projects (if any) conform to the Eclipse Foundation IP Policy and procedures.
In exceptional situations, such as Projects with zero active Committers or Projects with disruptive Committers and no effective Project Leader(s), the Project Leadership Chain has the authority to make changes (add, remove) to the set of Committers and/or Project Lead(s) of that Project.
|See guidelines and checklists for electing a new committer.|
The election process for Committers uses the open and transparent portal election system. The election process begins with an existing Committer on the same Project nominating the Contribtor. The Project's Committers will vote for a period of no less than one week of standard business days. If there are at least three (3) positive votes and no negative votes within the voting period, the Contributor is recommended to the root project's PMC for commit privileges. If there are three (3) or fewer Committers on the Project, a unanimous positive vote of all Committers is substituted. If the PMC approves, and the Contributor signs the appropriate Committer legal agreements established by the EMO (wherein, at the very least, the Developer agrees to abide by the Eclipse Intellectual Property Policy), the Contributor becomes a Committer and is given write access to the source code for that Project.
At times, Committers may become inactive for a variety of reasons. The decision making process of the Project relies on active committers who respond to discussions and vote in a constructive and timely manner. The Project Leaders are responsible for ensuring the smooth operation of the Project. A Committer who is disruptive, does not participate actively, or has been inactive for an extended period may have his or her commit status revoked by the Project Leaders. (Unless otherwise specified, "an extended period" is defined as "no activity for more than six months".)
Active participation in the user newsgroup and the appropriate developer mailing lists is a responsibility of all Committers, and is critical to the success of the Project. Committers are required to monitor and contribute to the user newsgroup.
Committers are required to monitor the mailing lists associated with the Project. This is a condition of being granted commit rights to the Project. It is mandatory because committers must participate in votes (which in some cases require a certain minimum number of votes) and must respond to the mailing list in a timely fashion in order to facilitate the smooth operation of the Project. When a Committer is granted commit rights they will be added to the appropriate mailing lists. A Committer must not be unsubscribed from a developer mailing list unless their associated commit privileges are also revoked.
Committers are required to track, participate in, and vote on, relevant discussions in their associated Projects and components. There are three voting responses: +1 (yes), -1 (no, or veto), and 0 (abstain).
Committers are responsible for proactively reporting problems in the bug tracking system, and annotating problem reports with status information, explanations, clarifications, or requests for more information from the submitter. Committers are responsible for updating problem reports when they have done work related to the problem.
Committer, PMC Lead, Project Lead, and Council Representative(s) are roles; an individual may take on more than one of these roles simultaneously.
- The Requirements Council is primarily responsible for the Eclipse Roadmap. There will always be more requirements than there are resources to satisfy them, thus the Requirements Council gathers, reviews, and categorizes all of these incoming requirements - from the entire Eclipse ecosystem - and proposes a coherent set of Themes and Priorities.
- The Planning Council is responsible for establishing a coordinated Simultaneous Release (a.k.a, "the release train") that supports the Themes and Priorities in the Roadmap. The Planning Council is responsible for cross-project planning, architectural issues, user interface conflicts, and all other coordination and integration issues. The Planning Council discharges its responsibility via collaborative evaluation, prioritization, and compromise.
- The Architecture Council is responsible for the development, articulation, and maintenance of the Eclipse Platform Architecture and ensuring the Principles of the Development Process through mentorship. Membership in the Architecture Council is per the Bylaws through Strategic Membership, PMCs, and by appointment. The Architecture Council will, at least annually, recommend to the EMO(ED), Eclipse Members who have sufficient experience, wisdom, and time to be appointed to the Architecture Council and serve as Mentors. Election as a Mentor is a highly visible confirmation of the Eclipse community's respect for the candidate's technical vision, good judgement, software development skills, past and future contributions to Eclipse. It is a role that should be neither given nor taken lightly. Appointed members of the Architecture Council are appointed to two year renewable terms.
See guidelines and checklists for the Architecture Council.
- Themes and Priorities from the Requirements Council
- Project Plans from Projects
The Roadmap is prepared by the Councils and approved by the Board annually. A proposed Roadmap or Roadmap update is disseminated to the Membership at Large for comment and feedback in advance of its adoption. This dissemination and all discussion and debate around the Roadmap must be held in an open and transparent public forum, such as mailing lists or newsgroups.
Prior to any Board vote to approve a Roadmap or Roadmap update, every Member has the right to communicate concerns and objections to the Board.
The process of producing or updating the Roadmap is expected to be iterative. An initial set of Themes and Priorities may be infeasible to implement in the desired timeframe; subsequent consideration may reveal new implementation alternatives or critical requirements that alter the team's perspective on priorities. The EMO orchestrates interaction among and within the Councils to drive the Roadmap to convergence.
This Development Process, the EMO, the Councils, and the Projects all acknowledge that the success of the Eclipse ecosystem is dependent on a balanced set of requirements and implementations. A Roadmap that provides too large a burden on the Projects will be rejected and ignored; similarly, a Roadmap that provides no predictable Project plans will be unhelpful to the business and technical plans being created by the ecosystem. A careful balance of demands and commitments is essential to the ongoing success of the Eclipse Projects, frameworks, and ecosystem.
The Project Leadership is expected to ensure that their Project Plans are consistent with the Roadmap, and that all plans, technical documents and reports are publicly available. To meet this requirement, each Project is required to create a transparently available Project Plan in an EMO-defined file format that meets the following criteria:
- Enumerates the areas of change in the frameworks and tools for each proposed Release
- Consistent with and categorized in terms of the themes and priorities of the Roadmap
- Identifies and accommodates cross-project dependencies
- Addresses requirements critical to the Ecosystem and/or the Membership at Large
- Advances the Project in functionality, quality, and performance
- the approved Roadmap is not put in jeopardy; and
- the work is consistent with the Project Plan criteria (as described above)
Projects must work within their Scope. Projects that desire to expand beyond their current Scope must seek an enlargement of their Scope using a public Review as described below.
All projects are required to report their status at least quarterly using the EMO defined status reporting procedures.
Projects must provide advanced notification of upcoming features and frameworks via their Project Plan.
The Mentors must attend the Creation and Graduation Reviews.
|See guidelines and checklists about writing a proposal.|
- The Pre-proposal phase ends when the Proposal is published by EMO and announced to the membership by the EMO.
|See guidelines and checklists about gathering support for a proposal.|
- The Proposal phase ends with a Creation Review or a Termination Review.
|See guidelines and checklists about incubation.|
- The Incubation phase may continue with a Continuation Review or a Release Review.
- Top-Level Projects cannot be incubated and can only be created from one or more existing Mature-phase Projects.
- The Incubation phase ends with a Graduation Review or a Termination Review.
|See guidelines and checklists for utilizing the Parallel IP process.|
|See guidelines and checklists about the mature phase.|
- Mature phase projects have Releases through Release Reviews.
- A Mature Project may be promoted to a Top-Level Project through a Promotion Review.
- A Mature Project that does not participate in a Release in given year may continue through a Continuation Review.
- Inactive Mature phase projects may be archived through a Termination Review.
|See guidelines and checklists about being a top-level project.|
|See guidelines and checklists for archiving projects.|
If there is sufficient community interest in reactivating an Archived Project, the Project will start again with Creation Review. As there must be good reasons to have moved a Project to the Archives, the Creation Review provides a sufficiently high bar to prove that those reasons are no longer valid. It also ensures that the original or updated project goals are still consistent with the Purposes and Roadmap.
All Projects are required to participate in at least one Review per year.
For each Review, the project leadership makes a presentation to, and receives feedback from, the Eclipse membership.
A Review is a fairly comprehensive process. Gathering the material for a Review and preparing the presentation is a non-trivial effort, but the introspection offered by this exercise is useful for the Project and results are very useful for the entire Eclipse community. In addition, Reviews have a specific relationship to the requirements of the Eclipse IP Policy.
All Reviews have the same general process:
- Projects are responsible for initiating the appropriate reviews. However, if a Project does not do so and the EMO believes a Review is necessary, the EMO may initiate a Review on the Project's behalf. The Project Leader initiates a review through the portal.2
- A Review then continues with the Project's Leadership requesting that the EMO(ED) schedule the Review.
- No less than one week in advance of the Review conference call, and preferably
at least two weeks in advance, the Project leadership provides the EMO with
the archival presentation material.
- The presentation material always includes a summary slide presentation or document. The minimum contents of the presentation are proscribed by the individual Review types.
- The presentation material must be available in a format that anyone in the Eclipse membership can review. For example, Microsoft Powerpoint files are not an acceptable single format - such files may be one of the formats, but not the only format. Similarly for Apple Keynote files and Microsoft Word files. PDF and HTML are acceptable single formats.
- The presentation material must have a correct copyright statement and license.
- The presentation material must be archival quality. This means that the materials must be comprehensible and complete on their own without requiring explanation by a human presenter, reference to a wiki, or to other non-archived web pages.
- The EMO announces the Review schedule and makes the presentation materials available to the membership-at-large.
- Clear evidence that the project has vibrant committer, adopter and user communities as appropriate for the type of Review.
- Reasonable diversity in its committer population as appropriate for the type of Review. Diversity status must be provided not only as number of people/companies, but also in terms of effort provided by those people/companies.
- Documented completion of all required due diligence under the Eclipse IP Policy.
- For Continuation, Graduation and Release Reviews, the project must have a current project plan, in the format specified by the EMO, available to the community.
- Balanced progress in creating both frameworks and extensible, exemplary tools.
- Showcase the project's quality through project-team chosen metrics and measures, e.g., coupling, cyclomatic complexity, test/code coverage, documentation of extensions points, etc.
2Until such time as the Foundation portal supports initiating Reviews, email to the EMO will suffice.
The Review itself:
- The Review is open for no less than one week and usually no more than two weeks of generally accepted business days. This is the Review period.
- The Review begins with the EMO's posting of the review materials at the start of the Review period, and ends with either the end of the Review period or (see below) an optional conference call or other conference technology (e.g., web conferencing) so long as the technology is available to all members and incurs no additional costs to the attendees.
- The proper functioning of the Eclipse Development Process is contingent on the active participation of the Eclipse Members and Committers, especially in Reviews, thus each Review has an EMO-designated discussion and feedback communication channel: a newgroup, a mailing list, or some other public forum.
- If a Committer election is required for a Review (for example, for a Move Review), then it is held simultaneously with the Review period. Thus the election and the Review will end at the same time, allowing quick and efficient provisioning of the resulting Project.
- Simultaneously with the opening of the Review,
a date and time for the optional conference call is announced. The call date shall be
no less than the next day and no more than one week of standard business days after
the last day of the Review. (For example, if the Review runs from Wednesday the 4th through
Tuesday the 10th, the call may be previously scheduled for any time from Wednesday the 11th through
Wednesday the 18th.)
The default is that the optional conference call not be held. However, during the Review period, any Eclipse Member with voting rights may request, via the Review's public communication channel, that the conference call be held. If any such requests exist at the end of the Review period, the conference call is held at its previously scheduled date and time.
- During the conference call, the Project Leadership (or EMO appointed Project representative) provides a brief summary of the reasons and justifications for the phase transition followed by a question and answer session.
- The EMO(ED) approves or fails the Review based on the public comments, the scope of the Project, and the Purposes of the Eclipse Foundation as defined in the Bylaws. The EMO(ED) announces the result in the defined Review communication channel.
If any Member believes that the EMO has acted incorrectly in approving or failing a Review may appeal to the Board to review the EMO's decision.
|See guidelines and checklists about Creation Reviews.|
The Creation Review archival documents must include short nomination bios of the proposed initial committers. These bios should discuss their relationship to, and history with, the incoming code and/or their involvement with the area/technologies covered by the proposal. The goal is to help keep any legacy contributors connected to new project and explain that connection to the current and future Eclipse membership, as well as justify the initial Committers' participation in a meritocracy. (See )
|See guidelines and checklists about Graduation Reviews.|
- a working and demonstratable code base of sufficiently high quality
- active and sufficiently diverse communities appropriate to the size of the graduating code base: adopters, developers, and users
- operating fully in the open following the Principles and Purposes of Eclipse
- a credit to Eclipse and is functioning well within the larger Eclipse community
|See guidelines and checklists about Release Reviews.|
|See Termination Review "How To" for more information.|
|See Move Review "How To" for more information about Move Reviews.|
The purpose of a Move Review is to verify that there are no IP Legal impediments to the proposed move of code from one Project to another Project, and to act as an election (if necessary) for the Committers who are being added to the new Project.
There are four Move Review cases:
- A subset of code is moving out of one Project (A) and into another Project (B). -- Project B's Committers may not have new committers imposed upon them, thus project B's Committers must elect (the subset of) Project A's Committers who are moving with the code to Project B.3
- An entire Project's (A) code is moving into another Project (B) and Project A is being terminated. -- Same as above: Project B's Committers must elect Project A's Committers to committer status on Project B.
- An entire Project (A) is moving from one parent Project (P) to another parent Project (Q). -- No Committers are changing Operating Projects, thus no elections are necessary.
- Code is moving out of one Project (A) and starting a new Project (C). -- This is a Creation Review, not a Move Review. Project C committers will be defined by the Creation Review.
3Until such time as the Foundation portal supports Committer election-style voting for Move Reviews, an election held on the destination Project's developer mailing list will suffice.
If a Restructuring Review involves combining two or more Committer populations, each Committer population must elect the other3, in order to explicitly maintain the principle of not allowing any Committer population to have new Committers imposed there upon.Apache Software Foundation Releases FAQ. The Eclipse community has many of the same beliefs about Releases as does the Apache community and their words were already excellent. The Apache Software Foundation Releases FAQ is distributed under the Apache License, Version 2.0.)
Releases are, by definition, anything that is distributed outside of the Committers of a Project. If users are being directed to download a build, then that build has been released (modulo the exceptions below). All Projects and Committers must obey the Eclipse Foundation requirements on approving any release.
(Exception 1: nightly and integration builds) During the process of developing software and preparing a Release, various nightly and integration builds are made available to the developer community for testing purposes. Do not include any links on the project website, blogs, wikis, etc. that might encourage non-early-adopters to download and use nightly builds, release candidates, or any other similar package (links aimed at early-adopters and the project's developers are both permitted and encouaged). The only people who are supposed to know about such packages are the people following the developer mailing list and thus are aware of the limitations of such builds.
(Exception 2: milestone and release candidate builds) Projects are encouraged to use an agile development process including regular milestones (for example, six week milestones). Milestones and release candidates are "almost releases" intended for adoption and testing by early adopters. Projects are allowed to have links on the project website, blogs, wikis, etc. to encourage these outside-the-committer-circle early adopters to download and test the milestones and release candidates, but such communications must include caveats explaining that these are not official Releases.
- Milestones are to be labeled
x.yMz, e.g., 2.3M1 (milestone 1 towards version 2.3), 2.3M2 (milestone 2 towards version 2.3), etc.
- Release candidates are to be labeled
x.yRCz, e.g., 2.3RC1 (release candidate 1 towards version 2.3).
- Official Releases are the only downloads allowed to be labeled with
x.y, e.g., 0.5, 1.0, 2.3, etc.
All official Releases must have a successful Release Review before being made available for download.
(Exception 3: bug fix releases with no new features) Bug fix releases (x.y.z, e.g., 2.3.1) with no new features over the base release (e.g., 2.3) are allowed to be released without an additional Release Review. If a bug fix release contains new features, then the Project must have a full Release Review.
Under no circumstances are builds and milestones to be used as a substitute for doing proper official Releases. Proper Release management and reviews is a key aspect of Eclipse Quality.
Member concerns may include:
- Out of Scope. It is alleged that a Project is exceeding its approved scope.
- Inconsistent with Purposes. It is alleged that a Project is inconsistent with the Roadmap and/or Purposes.
- Dysfunctional. It is alleged that a Project is not functioning correctly or is in violation of one or more requirements of the Development Process.
- Contributor Appeal. It is alleged that a Contributor who desires to be a Committer is not being treated fairly.
- Invalid Veto. It is alleged that a -1 vote on a Review is not in the interests of the Project and/or of Eclipse.
Due to the continued evolution of the Eclipse technology, the Eclipse community, and the software marketplace, it is expected that the Development Process (this document) will be reviewed and revised on at least an annual basis. The timeline for that review should be chosen so as to incorporate the lessons of the previous annual coordinate release and to be applied to the next annual coordinated release.
The EMO is further responsible for ensuring that all plans, documents and reports produced in accordance with this Development Process be made available to the Membership at Large via an appropriate mechanism in a timely, effective manner.