fwiw: last year a concrete proposal was made that seemed to have consensus “Move NodeStore implementations into their own modules" http://markmail.org/message/6ylxk4twdi2lzfdz
Agree that nothing happened - but I believe that this move might again find consenus On 27/10/16 10:49, "Francesco Mari" <[email protected]> wrote: >We keep having this conversation regularly but nothing ever changes. >As much as I would like to push the modularization effort forward, I >recognize that the majority of the team is either not in favour or >openly against it. I don't want to disrupt the way most of us are used >to work. Michael Dürig already provided an extensive list of what we >will be missing if we keep writing software the way we do, so I'm not >going to repeat it. The most sensible thing to do is, in my humble >opinion, accept the decision of the majority. > >2016-10-27 11:05 GMT+02:00 Davide Giannella <[email protected]>: >> 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 >> >>
