We would like to have Eclipse aCute (for C# development in Eclipse IDE) included in the SImultaneous Release and did announce it the cross-project-issues-dev.
The issue is that the current quality of aCute is not sufficient for us to consider as ready for SimRel, and this depends mostly on some change in an upstream non-Eclipse.org project we're using (OmniSharp). As soon as OmniSharp releases a newer version including the change we're waiting for, aCute should be safe to go into SimRel.
The big issue is that we don't know, nor have the power/influence to estimate or change, when OmniSharp will release our needed feature. So we cannot actually commit on a date when aCute can be perceived as good enough for SimRel.
Wayne informed that as of now, the SimRel process doesn't have a path for such projects who would like to be part of SimRel but cannot guarantee they'll be able to actually be in; and suggested that I ask the PMC to cascade the request to Planning Council.
One important thing to note in this discussion is that we do not expect any other Eclipse.org project to depend on aCute. aCute has no public API, is still incubating, and we wouldn't advise anyone to start building on top of it. So, hopefully, the presence or not of aCute in SimRel shouldn't affect any other project.
My impression in that for this case, we could ask the Planning Council to set up a new rule to allow such "we'd like to get it but we're not sure we'll be able" projects to come in or out late in the release train, if it's clear that no other project should build on top of it and if project (aCute in that case) agrees to some constraints that Planning Council would consider necessary.
Can you please bring this to the next Planning Council and advise?