Vadim Gritsenko wrote:
Carsten Ziegeler wrote:
<snip about="2.1.1 versus 2.2" />
We decided to create a new repository for each major version, so this would require to create a cocoon-2.2 repository.
Another thing to keep in mind is that if everybody starts developing 2.2 and nobody works on 2.1+, then it makes sense to copy all of the blocks to 2.2 as well, and 2.1 will become "historical".
...
while this makes sense I thought Carsten was trying to solve another issue with his 'keep blocks in 2.1' idea
2.2 should introduce the so called 'real blocks' and as such will require a different setup/build/... which is most likely to be reflected in a split repository for the blocks... So I guess in a 2.2 focus on real blocks one would never want to have the source of the blocks inside the same repo, right?
combining both your ideas we could go for a cocoon-blocks repository as soon as the cocoon-2.2 starts?
(by doing a per-block-sub-dir checkout of cocoon-blocks this would autmatically allow for single-block-checkout so putting all blocks in one repo seems no blocking thing on short notice)
By this we have a simple way of starting development of the "real blocks" and all the other nice changes we have in mind.
We have then time to think about how to handle blocks regarding cvs. I could imagine to create own repositories for some "bigger" blocks etc. But it's best to take small and simple steps for now.
And the first small step would be to create a plan for the future development. Some of the development - as those enhancements to request parsing - can easily go into 2.1.1.
Vadim
-marc= -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://radio.weblogs.com/0116284/ [EMAIL PROTECTED] [EMAIL PROTECTED]
