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 Mon, 09 Feb 2015 20:47:34 GMT

    [ 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

View raw message