The Eclipse Foundation Development Process (EDP) operates at a project, not component level. The EDP has no formal notion of component.
The default is that projects have project-wide releases with a single release review that cover all of the project content. There is a provision in the EDP that facilitates a project creating a release that includes only part of the project content in cases where that is necessary. Some projects, for example, release components on vastly different or uncoordinated schedules (e.g., MicroProfile). We've been doing this for individual Jakarta EE specifications (this makes more sense to me, since the Jakarta EE specification committee prefers separate ballots for individual specifications).
There is no requirement that component version numbers match the project version number. In fact, it is relatively common that they do not (e.g., the Eclipse Platform 4.17 release includes components that are version 1.0). Following a successful release review, the project can release the components in whatever order makes sense. There's no requirement that components all be released at exactly the same time, only that they be released within a year of a successful release review (note that specification projects are different: they are required to engage in a release review for every release).
All of this is to say that I don't think that there is any benefit in having Eclipse Glassfish engage in multiple release reviews.
I'm thinking that we get the project team to change the description of the Eclipse Glassfish 6.0 release
to include a list of the components and respective versions, set the release review
date to December 9 and call it day.