[ 
https://issues.apache.org/jira/browse/OAK-3842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15091618#comment-15091618
 ] 

Konrad Windszus commented on OAK-3842:
--------------------------------------

Maybe then it would be a good idea to collect in a separate ticket what should 
end up in a dedicated API package in the mid term (because the classes are 
useful for other consumers than Oak itself) and use this ticket only for 
deciding which parts of the bundle should now be under semantic versioning 
rules (without any refactoring of classes/packages).

> Adjust package export declarations 
> -----------------------------------
>
>                 Key: OAK-3842
>                 URL: https://issues.apache.org/jira/browse/OAK-3842
>             Project: Jackrabbit Oak
>          Issue Type: Task
>            Reporter: Michael Dürig
>            Assignee: Michael Dürig
>            Priority: Critical
>              Labels: api, modularization, technical_debt
>             Fix For: 1.4
>
>
> We need to adjust the package export declarations such that they become 
> manageable with our branch / release model. 
> See http://markmail.org/thread/5g3viq5pwtdryapr for discussion.
> I propose to remove package export declarations from all packages that we 
> don't consider public API / SPI beyond Oak itself. This would allow us to 
> evolve Oak internal stuff (e.g. things used across Oak modules) freely 
> without having to worry about merges to branches messing up semantic 
> versioning. OTOH it would force us to keep externally facing public API / SPI 
> reasonably stable also across the branches. Furthermore such an approach 
> would send the right signal to Oak API / SPI consumers regarding the 
> stability assumptions they can make. 
> An external API / SPI having a (transitive) dependency on internals might be 
> troublesome. In doubt I would remove the export version here until we can 
> make reasonable guarantees (either through decoupling the code or stabilising 
> the dependencies). 
> I would start digging through the export version and prepare an initial 
> proposal for further discussion. 
> /cc [~frm], [~chetanm], [~mmarth]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to