I read through the vanilla EFSP [1] and the document on specializing the process [2].
I don't personally see anything we need to customize given our past OSGi behaviors.
The only concern I have with the EFSP is the fairly tight coupling between a Specification Versions [3] and Compatible Implementations (CI) [4] especially with respect to ratifying [5] the release candidate specification version into the final specification. Generally open source projects (where we will get most of our CIs), do not want to make releases based upon non-final OSGi API. For example, Apache Felix has a policy of not releasing using non-final OSGi API [6]. But a final OSGi specification release will require at least one compatible implementation.
OSGi always had similar issues but did not have such a strict coupling between a final spec release and the CI. We often used non-final CIs and will need to continue to do this in the OSGi WG to break the "finality cycle" between the final APIs and the CI. I don't see anyway we can use a final CI as the CI for ratifying a specification version as final. We will need to work this out with the CI providing open source projects like Eclipse Equinox and Apache Felix to request they release release candidate (RC) versions to maven central based upon RC OSGi API releases in maven central to use as CIs when ratifying a specification version as final.
--
BJ Hargrave
Senior Technical Staff Member, IBM // office: +1 386 848 1781
OSGi Fellow and OSGi Specification Project lead // mobile: +1 386 848 3788
hargrave@xxxxxxxxxx
