[ https://issues.apache.org/jira/browse/OAK-10252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julian Reschke updated OAK-10252: --------------------------------- Labels: candidate_oak_1_22 (was: ) > Distinguish in oak-jackrabbit-api between provider and consumer type > interfaces > ------------------------------------------------------------------------------- > > Key: OAK-10252 > URL: https://issues.apache.org/jira/browse/OAK-10252 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: jackrabbit-api > Reporter: Konrad Windszus > Assignee: Konrad Windszus > Priority: Major > Labels: candidate_oak_1_22 > Fix For: 1.54.0 > > > Currently there is almost no annotation related to Provider or Consumer type > maintained on the interfaces of > https://github.com/apache/jackrabbit-oak/tree/trunk/oak-jackrabbit-api. > That leads to a default of almost all interfaces being assumed ConsumerType > and therefore requiring all backwards-incompatible changes (for > implementations) a major version increment (which breaks every consuming > bundle). > For ProviderType interfaces > (https://docs.osgi.org/javadoc/osgi.annotation/7.0.0/org/osgi/annotation/versioning/ProviderType.html) > bq. A non-binary-compatible change to a provider type normally requires > incrementing the major version of the type's package. This change will > require all providers and all consumers to be updated to handle the change. > However, a non-binary-compatible change affecting a protected access member > only requires incrementing the minor version of the type's package. This > change will require all providers to be updated to handle the change, but > consumers will not require changes since they only use, and do not extend, > the provider type and thus could not access protected access members of the > provider type. > While for ConsumerType interfaces (the default) > (https://docs.osgi.org/javadoc/osgi.annotation/7.0.0/org/osgi/annotation/versioning/ConsumerType.html) > bq. A non-binary-compatible change to a consumer type or a binary-compatible > change to a consumer type affecting an abstract method normally requires > incrementing the major version of the type's package. This change will > require all providers and all consumers to be updated to handle the change > since consumers that implement or extend the consumer type and all providers > must understand the change in the consumer type. -- This message was sent by Atlassian Jira (v8.20.10#820010)