Hi Tommaso, 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.
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 At least so far, in my view we saw Oak as one library. If we were to change that then we would need to be much more careful about the interactions between the various (internal) modules. So far, these are an implementation detail which we can change at will if needed - which obviously allows for quite some flexibility on internal changes. my2c Michael
