+1 from me on Tom's proposal too. Kind regards,
David On Thu, 5 Aug 2021 at 13:22, Thomas Watson <[email protected]> wrote: > Hi JB, > > The spec itself will publish release candidate artifacts. At that time the > Felix project can publish its own release candidate based off the OSGi > specification release candidate. > > Assuming all the OSGi Specification project tests pass with the published > Felix release candidate implementation then the OSGi working group will be > able to proceed with the final voting and publishing of the release final > artifacts for the new OSGi specification version. Only after that will > Felix then be able to proceed with publishing a final release of the > implementation artifact (SCR bundle). > > Hope that makes things clear. > > Thanks > > Tom > > > On Wed, Aug 4, 2021 at 11:53 PM Jean-Baptiste Onofré <[email protected]> > wrote: > > > Hi, > > > > I agree to release RC or Milestone. > > > > Now, will the spec release before the impl ? If so, we can cut > > "official" release with the impl. > > If not, then, agree for RC releases. > > > > Regards > > JB > > > > On 04/08/2021 18:47, Thomas Watson wrote: > > > Hi, > > > > > > Now that the OSGi specification development has resumed under the > Eclipse > > > OSGi Working Group we need to discuss how the OSGi Working Group will > > > consume compatible implementations done within the Apache Felix > project. > > > > > > For the immediate discussion I have been developing the OSGi R8 > > Declarative > > > Services implementation in the scrR8 branch [1]. The Apache Felix SCR > > > implementation has been used as the reference implementation for past > > > releases of the OSGi specification. This process has changed somewhat > > now > > > that the specification is being developed at the Eclipse OSGi Working > > > Group. There no longer will be something called a "reference" > > > implementation. Instead there will be one or more implementations that > > are > > > "compatible" implementations. In order for the OSGI specification to > > have > > > a final release vote there must be one or more (non-snapshot) > compatible > > > implementations publically available from an open source project. > > > > > > As far as I know, the Apache Felix project has a policy of never > having a > > > release of an artifact that contains non-final OSGi specification > > classes. > > > This leaves the OSGi Working Group with a circularity issue because it > > > cannot have a final release vote of the R8 Declarative Services > > > specification until there is a publically available (non-snapshot) > > > compatible implementation but Apache Felix will not publish a > > non-snapshot > > > version of SCR R8 implementation to maven central until there is are > > final > > > spec API JARs available for the SCR R8 specification. > > > > > > The proposed process from the OSGi working group is to have open source > > > projects providing a compatible implementation that is used for the > > > specification voting would provide a milestone version (M1, M2, etc.) > or > > > release candidate version (RC1, RC2, etc.) to maven central. These > > > implementations would build against available release candidate OSGI > API > > > JARs from maven central. Then the OSGi Specification project build > would > > > use the compatible implementation's milestone or release candidate from > > > maven central to build its final version for voting and releasing the > > final > > > specification artifacts. > > > > > > I propose the Felix project allow releases of milestones and/or release > > > candidates with relaxed rules for including non-final OSGi APIs. Such > a > > > milestone or RC release may depend on release candidate API JARs > > published > > > to maven central by the OSGi Specification project. After the OSGi > > > specification goes final we can then do a final release of the > > > implementation at our leisure. Is this something we can do in the > Apache > > > Felix project? > > > > > > Tom > > > > > > [1] https://github.com/apache/felix-dev/tree/scrR8 > > > > > >
