I fully agree with what Thomas is saying. Being on the inside of the segment-tar release cycles I don't really see the need or the advantages of a decoupled release, it seems it only managed to separate us even more (we even have a different release email template, if that was ever needed) without really providing any benefits: there is no segment-tar without oak-*, no one would expect to be able to just drop in the latest segment-tar bundle, everyone asks what the *oak* version is that goes with each segment release, maybe this will change, maybe not, but that's how it is now. So for me personally, the overhead of the separate release greatly outweighs the benefits.
> 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. There's a lot of misrepresentation packed into this. First it would be good to maintain a respectful & objective attitude towards the list. Second, we release every two weeks from a development branch to reduce the feedback loop, if something breaks we can catch it early. Releases are unstable and frequent, I saw no one else complain about this before. Third, releases are generally cheap, why does it matter how often we release the parent POM? Are you worried about disk space? Confused customers? What part of this seems _nonsense_? I'm all for going forward on the things that matter to the overall project, but I'm not convinced separate release cycles for all modules is what was keeping Oak from graduating from 'pet project' level to the big league. I would rather keep this as simple as it can be for everyone, not just segment-tar. best, alex On Fri, Oct 21, 2016 at 4:22 PM, Julian Reschke <[email protected]> wrote: > On 2016-10-21 16:15, Thomas Mueller wrote: > >> 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 >> > > Big +1. > > Best regards, Julian > >
