Wow, quite some replies :) See in-line, trying to replying to everyone in one email
On 21/10/2016 13:08, Thomas Mueller wrote: > 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. As one of the people who deal with the releases mainly this will help greatly. However I have to ask here: is this what we want? I'm not expressing any opinion. I'm simply asking what are we expecting to have from oak. If we're expecting to reuse segment-tar somewhere else, in other projects, then modularity is the way to go. However anyone willing to use segment-tar outside of Oak will have deal with quite a bunch of dependencies: oak-core in primis. If we're speaking of having a separate release cycle just for being free from the Oak rc, then we better reconsider the move, as we're releasing trunk every two weeks, which is quite frequent and allows for testing in third party products. On 21/10/2016 14:04, Julian Sedding wrote: > While this may be possible, an arguably simpler solution would be to > give oak-run and oak-upgrade a separate lifecycle. They are consumers > of both segment-tar and oak-core (+ other bundles with same release > cycle). Hence they require interoperable releases of both *before* > they themselves can be released. +1 In general. However, while it will solve the oak dependencies from itself, which is already a big win, it won't solve third party dependencies problems. Read it other applications leveraging Oak+segment. For those we still need either oak-core-api (for example) or a single monolithic release. Again I don't mind one or the other, but we have to decide and act for good, not half solutions. On 21/10/2016 14:09, Francesco Mari wrote: > ...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. Yes it's true. However I don't see any issues here. It's simplifying a lot our process and no one else is depending on oak-parent afaik. If segment-tar depends on oak-parent then it makes sense to have a different release cycle for oak-parent as well. We're back at the previous point though, we have to do it well or not. We can't stay in the middle-ground. On 21/10/2016 16:41, Alex Parvulescu wrote: > ...everyone asks what the *oak* version is that > goes with each segment release,... This has been another topic I've been willing to bring up for a while. I've eased my life a bit with a script (if that could help) https://github.com/davidegiannella/misc/blob/master/oaky-stuff/oak-dependecies.sh. However as of the interdependencies we're speaking of it doesn't really reflect the truth. See oak 1.5.12 and segment 0.0.14. On 24/10/2016 12:48, Michael Marth wrote: (and Tommaso) > I agree with your assessment that this discussion is actually about the > delivery granularity and user’s consumption of Oak. Taking the freedom to > re-phrase what you said above: > > * either a complete library that is consumed as a whole (and where the > various internal modules are implementation details) > * Or a set of modules where users are expected and allowed to access the > modules directly and deploy arbitrary subsets of modules and here's the point. As said above. Where are willing to go? What are the advantages? Disadvantages? Let's make a decision and then move for good. Not half-way. However we still have the original problem to address: how are we planning to solve segment depending on oak depending on segment on third party applications? I have two proposals here that we could vote on if we want 1) Going back to monolithic? Read it as, segment-tar won't be released any more on its own cycle. 2) We correctly address dependencies. For example adding oak-core-api. Davide
