Hi Ian, Thanks for starting the discussion. I think this can be one of the big benefits of modularising Oak and I am interested in seeing this being done.
As you mentioned, it becomes easier to integrate various Oak changes, especially for consumers only depending on stable APIs. On Thu, 2017-10-05 at 13:33 +0100, Ian Boston wrote: > Obviously bundles remain the release unit, and the build must include > OSGi > based integration tests that validate a release is viable. This brings about a question - what is an Oak release? If doing per- module releases, will we also do a "product" releases? A product release in my view is - similar to the Sling Launchpad - a way of saying 'these module versions are guaranteed to work together beyond compilation and semantic versioning constraints'. Also of interest is how/if we want to address the issue of supporting various module versions combinations. So if we have ( for instance ) - oak-api 1.7.9 - oak-core 1.7.12 - oak-segment-tar 1.8.0 will these work together? Furthermore, which versions of oak-upgrade and oak-run are compatible with this combination? We should have these discussion first, and then (hopefully) switch to a more modular release process. Thanks, Robert
