Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Development Resources/HOWTO/Mature Phase"

((4) Release Reviews)
Line 8: Line 8:
 
</blockquote>
 
</blockquote>
  
==(1) What is Mature Phase?==
+
==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 [http://www.eclipse.org/projects/dev_process/development_process.php#2_1_Open_Source_Rules_of_Engagement open, transparent, and meritocractic] behavior. The project is regularly and predictably releasing [http://www.eclipse.org/org/documents/Eclipse_IP_Policy.pdf IP clean] extensible frameworks and exemplary tools. The project is actively nurturing the [http://www.eclipse.org/projects/dev_process/development_process.php#2_5_Three_Communities three communities]: developers, adopters, and users.
 
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 [http://www.eclipse.org/projects/dev_process/development_process.php#2_1_Open_Source_Rules_of_Engagement open, transparent, and meritocractic] behavior. The project is regularly and predictably releasing [http://www.eclipse.org/org/documents/Eclipse_IP_Policy.pdf IP clean] extensible frameworks and exemplary tools. The project is actively nurturing the [http://www.eclipse.org/projects/dev_process/development_process.php#2_5_Three_Communities three communities]: developers, adopters, and users.
  
==(2) Operations and Logistics==
+
==Operations and Logistics==
 
For the day-to-day and week-to-week guidelines and requirements
 
For the day-to-day and week-to-week guidelines and requirements
 
for running an Eclipse Project, please see the following:
 
for running an Eclipse Project, please see the following:
* [http://www.eclipse.org/projects/dev_process/project-operations.php words of wisdom and bits of advice]
+
* [[Development Resources/Words of Wisdom and Bits of Advice | words of wisdom and bits of advice]]; and
 
* [[Development Resources|how-tos, checklists, and guidelines]]
 
* [[Development Resources|how-tos, checklists, and guidelines]]
  
==(3) The Schedule==
+
==The Schedule==
 
There are many things that make Eclipse great. One is that there has been a strong emphasis on [http://www.eclipse.org/projects/dev_process/eclipse-quality.php quality]; another is the equally strong emphasis on [http://www.eclipse.org/projects/dev_process/development_process.php#2_2_Quality_Culture predictability]. Even more important than having a
 
There are many things that make Eclipse great. One is that there has been a strong emphasis on [http://www.eclipse.org/projects/dev_process/eclipse-quality.php quality]; another is the equally strong emphasis on [http://www.eclipse.org/projects/dev_process/development_process.php#2_2_Quality_Culture 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.
 
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.
Line 24: Line 24:
 
tools.
 
tools.
  
==(4) Release Reviews==
+
==Release Reviews==
 
Each major release (where <i>major</i> is defined as any release whose N or M version number changes in the N.M.P version number) must go through a [http://www.eclipse.org/projects/dev_process/release-review.php 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.
 
Each major release (where <i>major</i> is defined as any release whose N or M version number changes in the N.M.P version number) must go through a [http://www.eclipse.org/projects/dev_process/release-review.php 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.
  

Revision as of 12:51, 24 August 2010

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 Anne Jacko and Wayne Beaton (Eclipse Foundation)

Copyright © Eclipse Foundation, Inc. All Rights Reserved.