Il giorno ven 21 ott 2016 alle ore 16:08 Thomas Mueller <[email protected]>
ha scritto:
> Hi,
>
> >The release process in Oak is a joke.
>
> I don't think it's a joke.
>
> > Releasing every two weeks by
> >using version numbers as counters just for the sake of it is
> >embarrassing.
>
> Why? It's simple.
>
> > 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.
>
> "Nonsense"... again a word without explanation.
>
my understanding of it is that probably it doesn't make much sense to
release every time a new version of oak-parent that doesn't contain
anything new.
>
> >We shouldn't go backward, but forward.
>
> It depends on what "backward is". I would prefer if we make things
> "simpler".
>
> > We need to extract APIs into
> >their own independently released bundles.
>
> I don't think we need to do that. The "release everything at once" sounds
> good to me.
>
> > We should split oak-run in
> >different CLI utility modules
>
> Split, split, and again split. Why? What is the advantage?
>
> >, so that every implementation can take
> >better care of their own utilities.
>
> It's the Oak utilities. I think the current organization is just fine.
>
> >Oak is not a pet project
>
> Again, you are using strong words ("pet"), but without real explanation...
> How is it that your definition of "pet" is the only valid one?
>
> >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.
>
> Again a strong word... "dump".
>
> I just don't see how making tiny "ravioli" modules makes things any
> better.
sorry, as an Italian I need a clarification on this (ravioli architecture,
nice sounding).
> It surely makes things more complex, as we see with
> oak-segment-tar: it forces to add even more and more modules, to be able
> to deal with the consequences of adding modules.
>
In my opinion what we're discussing is our view on how Oak should be
architectured, either as a big (layered) blackbox or as a set of reusable
(and interoperable) software components.
The "release all at once with version x.y" approach sounds to me more
inline with the former while the "release every module separately and
abstract APIs as much as possible" sounds more inline with the latter.
My 2 cents,
Tommaso
>
> Regards,
> Thomas
>
>
