The Eclipse Foundation Development Process (EDP) describes a release
as anything that is distributed for adoption outside of the committers of a project (effectively, if you stamp something with a version number and tell the general audience to download it, it's a release).
Further, the EDP describes a requirement for all Eclipse projects to engage in a review prior to creating a release. Traditionally, this has meant that an Eclipse project team must engage in a release review
. A few years ago, we added the notion of an equivalent progress review
; the primary difference between a release review and a progress review is that a release review is aligned with a specific release and a progress review is not.
Following a successful release or progress review, an Eclipse project team may make as many releases (major, minor, or service) as necessary for a full year before having to engage again. Note that whether the project team engages in a review or not, the project team is responsible for ensuring that all intellectual property contained in all releases has been vetted per the Eclipse Intellectual Property (IP) Due Diligence Process
. Note also that specification projects
are required to engage in a release review for every
If your project is due or overdue for a review, please engage with EMO at your earliest convenience.
The EMO is exploring an option by which we will initiate progress reviews on a project's behalf. Our thinking at the moment is that reviews start with the EMO doing a health check on the project to ensure that the project team is doing all the right things to be a good open source citizen and is correctly implementing the EDP and Eclipse IP Due Diligence Process, before engaging the project team and PMC to remediate any outstanding issues that we identify. The successful completion of an EMO-initiated progress review will put the project in a state where it can release for a full year without requiring an additional review. We're tracking the work here
Our hope is that we may be able to effectively eliminate release reviews and reduce the burden of implementing the EDP for both project teams and the EMO. It's still early in the process, but we're hopeful that we'll be able to make this work for most of our projects. Again, we're just starting this experiment: we're not actively soliciting volunteers or rolling this out at this point.
Due to the extra intellectual property burdens inherent in specification work, release reviews will continue to be required for specification releases.
The Eclipse Foundation community awards are back for 2021!
The Eclipse Foundation has a vibrant community of many dedicated individuals, who deserve to be recognized for their contributions. To recognize our community members, we will be presenting awards for Top Committer, Top Newcomer Evangelist, Top Contributor, and Lifetime Achievement at EclipseCon 2021
As these are community awards, we are asking the community to get involved by nominating someone they think is deserving of an award, and voting to select the winners. Nominations for all four of the awards will be collected via bugs on GitLab from May 3 to May 28, 2021. We will then hold voting for the Top Committer, Top Newcomer Evangelist, and Top Contributor awards. The Lifetime Achievement award winner will be selected by the Eclipse Foundation team.
Details on the awards, nominations, and voting can be found on the Eclipse Community Awards
The call for participation for EclipseCon 2021 is open. Don't miss your opportunity; propose a talk now
Director of Open Source Projects | Eclipse Foundation