On 27/10/2016 08:53, Michael Dürig wrote: > > +1. > > It would also help re. backporting, continuous integration, releasing, > testing, longevity, code reuse, maintainability, reducing technical > debt, deploying, stability, etc, etc...
While I can agree on the above, and the fact that now we have https://issues.apache.org/jira/browse/OAK-5007 in place, just for the sake or argument I would say that if we want to have any part of Oak with an independent release cycle we need to Have proper API packages that abstract things. Specially from oak-core As soon as we introduce a separate release cycle for a single module we have to look at a wider picture. What other modules are affected? Taking the example of segment-tar we saw that we need - oak-core-api (name can be changed) - independent releases of the oak tools: oak-run, oak-upgrade, ... - independent release cycle for parent/pom.xml - anything I'm missing? So if we want to go down that route than we have to do it properly and for good. Not half-way. Davide
