Hi Upfront I like the amended proposal of using a version < 1 and a mandatory attribute „provisional“ with value „felix“. As Neil said, BND will solve this for imports be it the bndtools or the maven bundle plugin.
Not declaring a version and thus using 0.0.0 will have BND generate a version-less import, which essentially means „any version“, which really is bad. All exports always should have an export version. Now, to Richard’s point: I think this is very valid and we better take good care here. If we include OSGi API in our releases it is a re-release of AL2 licensed bits. Key is re-release. If we release provisional OSGi API in the OSGi name space which has not been released by OSGi yet, we are essentially first-party releasing it. So before we go this route, I would like to have the OSGi Alliance make a statement on this topic. In fact, it would make sense for the alliance to make an official statement not only to the benefit of the Felix project but to the benefit of all OSGi-related projects at Apache and elsewhere. WDYT ? Regards Felix > Am 03.01.2017 um 10:46 schrieb David Bosschaert <david.bosscha...@gmail.com>: > > Hi Richard, > > On 23 December 2016 at 19:19, Richard S. Hall <he...@ungoverned.org> wrote: > >> I'm not for changing the policy. The whole point behind the policy is that >> anything that we released is in some way blessed and lives forever. If we >> release packages in the OSGi namespace, they look official even potentially >> after the OSGi Alliance dumps an RFC (ala Gogo). There is no way for us to >> retract a release. >> > > There will be org.osgi.something API but it will be with a version < 1, > like 0.1 or something like that. Additionally it will have the mandatory > attribute on it as discussed above something like provisional="felix". The > fact that the version is less than one means that it will never clash with > OSGi released API. These two factors mean that nobody will accidentally use > this API. The users will have to put the mandatory attribute on the import > in order to use it. > > >> >> So, yes, it makes the process a little bit of a pain, but that was sort of >> the point, so we could make the status clear. Besides, using a temporary >> package name until a spec if final and then doing a global search/replace >> when it goes final isn't really that painful. >> >> > I think that experience over the years tells us that the temporary package > name basically means that nobody uses it. I think that others on this > thread have echoed that the temporary package name doesn't work for them. > > As you say the process is a bit of a pain and my point is that this stands > in the way of adoption and feedback of new APIs. With this modification to > the policy adoption and feedback becomes easier and less painful while we > still retain the barriers that require people to consciously decide to use > the provisional API... > > Cheers, > > David
