[
https://issues.apache.org/jira/browse/FELIX-4785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14312855#comment-14312855
]
Carsten Ziegeler commented on FELIX-4785:
-----------------------------------------
Many of our users simply rely on releases, so we have a 1.8.2 with the API in
it and it's not deprecated. And we have the next release (probably 2.0.0) where
the package is still there but changed incompatible (to version 2.0). And in
this sense, users have no choice of simply upgrading the DS implementation as
API is simply gone without any (deprecation) warning.
I totally agree that the old API has a wrong model, but we provided it and it's
being used out there.
Now, in addition, it seems 1.8.2 has some bugs that are fixed in 2.0.0 - (it
seems there are cases where a change to a factory config is not causing a
reactivation of the component); so again updating to get just that fix is not
possible.
The other option I see is we provide a compat package, that implements the old
API based on the DTOs. So we clearly separated it and people upgrading install
two bundles.
> 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)
