Luckily for us this is not a computer science problem but an easier software engineering concern.
The release process in Oak is a joke. Releasing every two weeks by using version numbers as counters just for the sake of it is embarrassing. I don't even know how many releases of our parent POM we have, every one of them equal to the other, and this is nonsense. We shouldn't go backward, but forward. We need to extract APIs into their own independently released bundles. We should split oak-run in different CLI utility modules, so that every implementation can take better care of their own utilities. Oak is not a pet project and we have to admit that its current level of complexity doesn't allow us to use oak-core and oak-run as dumping grounds anymore. 2016-10-21 14:08 GMT+02:00 Thomas Mueller <[email protected]>: > Hi, > >> could adding an oak-core-api with independent lifecycle solve the >>situation? > > "All problems in computer science can be solved by another level of > indirection" > > I would prefer if we get oak-segment-tar in line with the rest of oak > (release it at the same time and so on). I understand, there are some > disadvantages. But I think all alternatives also have disadvantages. > > Regards, > Thomas > > > > > On 21/10/16 12:46, "Davide Giannella" <[email protected]> wrote: > >>Hello team, >> >>while integrating Oak with segment-tar in other products, I'm facing >>quite a struggle with a sort-of circular dependencies. We have >>segment-tar that depends on oak-core and then we have tools like oak-run >>or oak-upgrade which depends on both oak-core and segment-tar. >> >>this may not be an issue but in case of changes in the API, like for >>1.5.12 we have the following situation. 1.5.12 has been released with >>segment-tar 0.0.14 but this mix doesn't actually work on OSGi >>environment as of API changes. On the other hand, in order to release >>0.0.16 we need oak-core 1.5.12 with the changes. >> >>Now oak-run and other tools may fail, or at least be in an unknown >>situation. >> >>All of this is my understanding and I may be wrong, so please correct me >>if I'm wrong. I'm right, could adding an oak-core-api with independent >>lifecycle solve the situation? >> >>Davide >> >> >
