Skip to content

Graduation review to leave the Incubation phase

Execution

Proposal

Idea

Our last release review was for %v0.6 on 2022-07-07. So, after our %v0.10 release on 2023-06-30, we need another release review before we can do our next release.

Rather than a v0.11 release, I propose to go for a v1.0 release. I propose we graduate as a project, and leave the Incubation phase, moving to the Mature phase. I propose to combine the next release review with a graduation review, or rather, to do a progress review combined with a graduation review. I propose to do them at the end of August / start of September.

Graduation timeline

Projects are generally expected to leave the incubation phase within a year, see https://www.eclipse.org/projects/handbook/#starting-faq, question 9). In that regard, we're quite a bit overdue already.

Graduation criteria

There are some guidelines what to look for before graduating. From https://www.eclipse.org/projects/handbook/#6_3_2_Graduation_Review:

6.3.2 Graduation Review

The purpose of the Graduation Review is to mark a Project’s change from the Incubation Phase to the Mature Phase.

The Graduation Review confirms that the Project is/has:

  • A working and demonstrable 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.

A Graduation Review is generally combined with a progress or Release Review.

And from https://www.eclipse.org/projects/handbook/#release-graduation:

Graduation Reviews

The purpose of a graduation review is to confirm that the project has a working and demonstrable code base of sufficiently high quality active and sufficiently diverse communities; has adopters, developers, and users operating fully in the open following the Eclipse Foundation Development Process; and is a credit to Eclipse and is functioning well within the larger Eclipse community

Graduation reviews are generally combined with a progress review (typically, but not necessarily in advance of the open source project’s 1.0 release). Upon successful completion of a graduation review, a project will leave the incubation phase and be designated as a mature project.

For a graduation review, review documentation must be provided by the project team that includes demonstration of:

  • solid working code with stable APIs;
  • an established and growing community around the project;
  • diverse multi-organization committer/contributor/developer activity; and
  • operation in the open using open source rules of engagement.

The graduation review documentation should demonstrate that members have learned the ropes and logistics of being an Eclipse project. That is, the project "gets the Eclipse way".

I think:

  • We have a working codebase. In fact, we've had it since our v0.1 release. We test quite a bit before we release new versions as well.
  • We have rather stable APIs, especially in terms of what end users use. For instance, we don't just remove language and tool features, but deprecate them and only remove them years later. The CIF release notes provide evidence of this.
  • Our community is growing. We have two more committers than when we started. We are also getting more issues created by others, and even some merge requests. It could of course always be more, but we have grown and will try to keep growing.
  • Our 5 committers work for various organizations. In fact, I think only @bvanbeek and @ahofkamp have the same affiliations. Similarly, contributors are from multiple organizations.
  • I think we do well in following the Eclipse Foundation rules.

Combining reviews

It seems we could combine a release review with a graduation review. Or, rather than a release review, we could opt for a progress review. A release review and progress review are essentially the same, but differ in timing, one being tied to a release and the other not. From https://www.eclipse.org/projects/handbook/#6_3_9_Combining_Reviews:

6.3.9 Combining Reviews

Reviews can be combined at the discretion of the PMC and EMO. Multiple Projects may participate in a single Review. Similarly, multiple Review types can be engaged in simultaneously. A parent Project may, for example, engage in an aggregated Progress Review involving itself and some or all of its child Projects; a consolidated Restructuring Review may move the code for several Projects; or a Progress Review may be combined with a Graduation Review. When multiple Reviews are combined, the Review documentation must explicitly state all of the Projects and types of Reviews involved, and include the required information about each.

It should be noted that the purpose of combining Reviews is to better serve the community, rather than to reduce effort on the part of the Project (though it is fortunate when it does both). Combining a progress and Graduation Review, or aggregating a Progress Review of a Project and several of its child Projects generally makes sense. Combining Progress Reviews for multiple unrelated Projects most likely does not.

And from https://www.eclipse.org/projects/handbook/#progress-review:

Historically, Eclipse open source projects were required to engage in a release review before publishing an official release. The notion of a release review still exists, but is fundamentally the same as a progress review.

Progress and release reviews differ only in timing. A progress review can be scheduled at any point in a project’s release cycle; a release review tends to be scheduled at the end of the release cycle.

I propose a progress review to be combined with the graduation review. Similar things will be checked, and doing it twice seems needless work.

Review date

From https://www.eclipse.org/projects/handbook/#starting-creation-review:

Reviews — which run for a minimum of one week — are scheduled twice a month, generally concluding on the first and third Wednesday of each month.

I propose to aim for the first Wednesday of September 2023, so 2023-09-06 as the review conclusion date. We'll have to submit a few weeks earlier (end of August).

Edited by Dennis Hendriks

Copyright © Eclipse Foundation, Inc. All Rights Reserved.     Privacy Policy | Terms of Use | Copyright Agent