Sylvain Wallez wrote: > > Ah, so we'll have a 2.2 repo containing only those parts whose structure > will change, and keep the 2.1 repo as a "fallback" for those parts whose > structure is the same (but who may have been upgraded since 2.1.0) ? > > But how do we decide that some modifications should occur in 2.2 and not > in 2.1 ? > Yupp.
> >As I expect that we will end in a different structure when we > have real blocks (e.g. perhaps a blocks repository etc.) this > would be imho an easier migration strategy. > > > > That's right. With real blocks, we'll have several distinct CVS > repositories. But will we have distinct "kernel" and "core component" > blocks ? Should the kernel be really naked (in which case it may even > contain only the block manager and the main interfaces but nothing > else), or should it provide the common services used by every > application (e.g. WildcardMatcher, FileGenerator, HTMLSerializer, etc) ? > I'm not sure if we will have this distinction, so I thought perhaps moving them (generators etc) out and later move them into the core again is less pain then having to maintain two branches. Perhaps the latter one is easier, I honestly don't know. > >Does this make sense? > > > > Yep. But the granularity has to be found. Maybe we should wait for > Stefano's RT so that everybody has a common understanding of the > consequences of blocks on the Cocoon organisation. > Hmm, yes, but we could start the 2.2 repo with the current core source, so we have a starting point. I expect that blocks will require longer discussions and I personally don't want to wait with 2.2 for this. Carsten
