Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
SimRel/Simultaneous Release Policy FAQ
Policy FAQs
Can a new project or feature join a Simultaneous Service Release (SR1 or SR2)?
Yes, but still subject to all the other rules of the Eclipse Development Process and the Simultaneous Release Requirements. For example, if a "Release Review" is required by the EDP, it is still required, before being in an SR. A release review is normally not required for a maintenance release, if the maintenance is "bug fixes" only, but if a new feature is added (including an increase in minor version number) then according to the Eclipse Development Process a release review is required. All that is independent of the "Simultaneous Service Release" and Planning Council ... just normal Eclipse business. Similarly, something "new" must still meet all the other Simultaneous Release requirements, such as signed jars, 4 part versioning, etc. In particular, the addition must "do no harm". In practice this means it is relatively easy to change "leaf components", but more care and effort is required to change a "low level" feature.
When a project is already in Simultaneous Release, they can not add a "Major" release (that is, no API breaking change, must be backward compatible) ... only Minor (or Service) releases. Projects must follow the ramp down schedule for the SR. The bits for the new release or feature must be made available at RC1 and can not be introduced later than that. Bug fixes of course can be made during the release candidate cycle. Release review material must be available to the community by RC1 to document the changes and new features in the release.
Projects should "announce" on cross-project list if they do include new features in an SR, and they should carefully follow the versioning semantics and increment the minor version when they do (That is, there is no "cheating" semantics ... it will catch up with you eventually). When possible, it is best to include the new feature as "optional" ... so, for example, if adopters are "building products" on top of a Simultaneous Release they can omit the new feature if they desired (though, we know that is not literally possible, in every case).
Can a Simultaneous Release project include bundles or features from a project not in the Simultaneous Release?
It can "include" another Eclipse Project that is not in the Simultaneous Release, if that other other Eclipse Project has been released before, and if that other Eclipse project (still) meets all the requirements of a Release (such as correct about.html files, etc.) and also the extra requirements of Simultaneous Release (such as signed jars, etc.,). This is analogous to the use of "third party" bundles from Orbit, where the original authors clearly do not "participate" in the release ... but the bundles have all been through the IP process, are well formed, etc. Of course, it is only natural and polite to let the other Eclipse Project know that you are planning on doing this, and give them the right to comment or object if they had some reason too (for example, they might say, "oh, we didn't know you were using us, ok, we'll join the Sim. Release too" or they might say, "Please don't, we plan to come out with a new, incompatible release in August and contribute that in SR1" ... just to give some hypothetical examples of the importance of communication.
But, if a project has not been released before, then another project can not "include" it in their own released code, even for a normal Eclipse Foundation Release, much less a Simultaneous Release. For the sake of history, I'll note this topic was discussed at length in bug 370974.