The EDP defines only one type of Release Review. The requirement is that a project must engage in a successful Release Review before they can distribute a release (the IP Policy has a trigger that requires a review of the projects intellectual property tracking when we engage in a Release Review).
One exception to this is that a project can distribute a service release (bug fixes only) without first engaging in a Release Review. So, in a manner of speaking a the other type of Release Review is no Release Review at all.
Note that the Eclipse Architecture Council is in the process of changing the what that Releases and Reviews are done in Eclipse Development Process. Release Reviews take time and effort, and are bottle-necked on the PMC and EMO. The requirement to do a Release Review with every (major and minor) is therefore pretty limiting for projects that do frequent releases.
The current thinking is that we'll introduce a new type of Review that is exactly like a Release Review and require that projects engage in at least one of them every year (i.e. they can do all the releases that they want within a year of their last review). The Project Leadership chain will have the authority to compel projects to engage in a review if they feel shenanigans are afoot.
Release Reviews will then become a specialization of this new type of review with the added requirement that each review is attached to a specific release. I envision that the EFSP will require that Specification Projects engage in a Release Review before their Specification is adopted ("To adopt a Specification, the Specification Project must engage in a Release Review as defined by the Eclipse Development Process.")
HTH,
Wayne
