felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FELIX-4785) Incompatible SCR API
Date Fri, 06 Feb 2015 08:05:34 GMT

    [ 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)

Mime
View raw message