On 28.03.17 15:02, Raul-Nicolae Hudea wrote:
Hi,

I wasn’t aware that “releasing independently” is an option, and maybe even 
desired for future modules. This is currently proposed on 
https://issues.apache.org/jira/browse/OAK-4933.

If you have input on how to make it successful, please add your input there 
(I’d be interested in the lessons learned from the previous attempt, which I 
understand it was related to segment-tar).

We decoupled oak-segment-tar for some time from the Oak release cycle last year. This gave us a lot of additional flexibility and enhanced modularity. We were effectively able to just re-deploy oak-segment-tar in AEM. Something that was and is much harder otherwise.

The show stopper latter was that with this way of releasing it is difficult to align the version of oak-run (tooling) with the module. To fix this we would have had to also decouple the tooling. Something we didn't have the resources for at that point in time.

Michael


Thanks,
Raul

On 28/03/2017, 11:54, "Angela Schreiber" <[email protected]> wrote:

    i was about to write pretty much the same thing :-)

    regards
    angela

    On 28/03/17 09:09, "Michael Dürig" <[email protected]> wrote:

    >
    >As this is a new feature I would be interested in the motivation for
    >having to backport this. Generally we should only backport fixes for
    >defects.
    >
    >As Marcel mentions on the issue a better approach would be to release
    >this independently. If this is blocked by dependencies we should make an
    >effort to sort this out, as now is the time in the release cycle for
    >doing so.
    >
    >So for now -1 from my side to back porting this until
    >
    >a) we have a clear picture of the alternatives and
    >b) in the case of backporting, understand how we would ensure quality.
    >This is new code that was so far never exposed to the level of testing
    >people would expect from 1.6 code.
    >
    >Michael
    >
    >On 27.03.17 11:21, Raul-Nicolae Hudea wrote:
    >> Hi,
    >>
    >> I would like to backport OAK-4933 to 1.6. The impact should be minimal
    >>since the changes are about bringing the AzureBlobStore connector to 1.6.
    >>
    >> Changes are:
    >> - new module
    >> - changes in oak-run to support the azure data store
    >>
    >> Thanks,
    >> Raul
    >>
    >>



Reply via email to