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 > >
