Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Development Resources/HOWTO/Mature Phase
Contents
Guidelines for Mature Phase
See "6.2.4 Mature Phase" in the Eclipse Development Process.
The project team has demonstrated that they are an open-source project with an open and transparent process; an actively involved and growing community; and Eclipse Quality technology. The project is now a mature member of the Eclipse Community. Major releases continue to go through Release Reviews.
What is Mature Phase?
Most of the lifetime of an Eclipse Project is spent in the Mature Phase. A mature Eclipse project is one that is a good open source citizen with open, transparent, and meritocractic behavior. The project is regularly and predictably releasing IP clean extensible frameworks and exemplary tools. The project is actively nurturing the three communities: developers, adopters, and users.
Operations and Logistics
For the day-to-day and week-to-week guidelines and requirements for running an Eclipse Project, please see the following:
The Schedule
There are many things that make Eclipse great. One is that there has been a strong emphasis on quality; another is the equally strong emphasis on predictability. Even more important than having a schedule is having an honest schedule, so while projects should do their best not to change the schedule, they should work even harder to ensure that the schedule in an honest one. This is especially critical for Eclipse projects because the projects release extensible frameworks that other Eclipse members - individuals and ecosystem companies - build products and tools on top of. Those members make plans based on the Eclipse plans and thus changing the Eclipse plans can materially affect a large number of downstream players.
The best scheduling algorithm for this kind of "bottom of the dependency pile" development is to under-promise and over-deliver. Promise less and promise it later than the team thinks it can be delivered, then deliver more and deliver earlier. This is especially important in open-source because the project wants to allow enough time for the community to provide lots of good feedback - feedback that will result in a really great framework and outstanding exemplary tools.
Release Reviews
Each major release (where major is defined as any release whose N or M version number changes in the N.M.P version number) must go through a Release Review. Please schedule enough time to complete the Review and any potential remedial actions so as not to impact the project's release schedule.
A side note about release numbering: the Eclipse standard for release numbers is that the major number (N) changes upon breaking changes to the APIs, the minor number (M) changes when the APIs are the same but there is substantial new function, and the incremental number (P) changes for fix packs. Fix packs are API compatible, i.e., no change to the APIs.The major number (N) may also change for significant new features without having breaking API changes. For example, if framework Foo versions 4.0, 4.1, 4.2, and 4.3 has been available for a couple years, the latest release might have enough new significant features to justify version 5.0 even though the API compatibility would indicate version 4.4.
For details of the Release Review see the separate Guidelines for Release Reviews.
This page is moderated by the EMO (Eclipse Foundation)