[
https://issues.apache.org/jira/browse/FELIX-4785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14308818#comment-14308818
]
Carsten Ziegeler commented on FELIX-4785:
-----------------------------------------
I wasn't aware of the implications when the change happened, but I'm now and
It's not too late to discuss things .
I see your point, however the ScrService is widely used out in the field, it's
even mentioned in OSGi books - so if we remove it and update the API to 2.0
this makes it impossible to simply update to the new DS implementation; it
requires to change code - and the same is of course true if the service returns
no information. And we gave our users no warning or time to act accordingly as
we simply remove it from one version to the next.
I seriously think we have to find a compromise here - what about leaving it as
it is; the api is back, it's functional, it's deprecated, it uses the wrong
model - but it gives users a notice as it's deprecated - we could even add big
bold log message each time the api is used. And once we released the new DS
implementation, we remove the API so it's gone in the next version. WDYT?
> Incompatible SCR API
> --------------------
>
> Key: FELIX-4785
> URL: https://issues.apache.org/jira/browse/FELIX-4785
> Project: Felix
> Issue Type: Bug
> Affects Versions: scr-2.0.0
> Reporter: Carsten Ziegeler
> Assignee: Carsten Ziegeler
> Fix For: scr-2.0.0
>
>
> Current trunk contains version 2.0.0 of the org.apache.felix.scr API package.
> While this is a logical step, this makes the new implementation unusable as a
> drop-in replacement into existing installations which might use the 1.x
> version of that API.
> I think we should go a more moderate way, leave the 1.x version in but
> deprecate it and also provide the replacement API (if any). Then in one of
> the further versions along the road, we can remove the API. This gives our
> users a chance to migrate slowly
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
