Hi, On 6 October 2017 at 15:02, Robert Munteanu <[email protected]> wrote:
> 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? > Perhaps, there needs to be a Oak Quickstart jar to define a combination of jars that work. Perhaps that is oak-run ? Best Regards Ian > > We should have these discussion first, and then (hopefully) switch to a > more modular release process. > > Thanks, > > Robert >
