Hi, You are sure using many emotional, judgmental words and sentences like "joke", "embarrassing", "nonsense", "We shouldn't go backward, but forward", "pet project", "admit", "level of complexity", "doesn't allow", "dumping grounds". Your whole mail is very judgmental.
OK, I see you would like to split everything into tiny, tiny modules. Right now we already have many modules, and using a different release cycle for oak-segment-tar is not a problem. So your solution is to split things into even more modules. I see that, as you seem to be very emotional about that. But I don't agree that's the best solution. I prefer simple solutions, that don't require a lot of bureaucracy and overhead. I see no big value in "being able" to release things independently. In fact I think it's added overhead, with no value. Regards, Thomas On 21/10/16 15:09, "Francesco Mari" <[email protected]> wrote: >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 >>> >>> >>
