On Friday, Sep 19, 2003, at 15:05 Europe/Rome, Geoff Howard wrote:
Sylvain Wallez wrote:Steven Noels wrote:Carsten Ziegeler wrote:
<snip type="happy agreement"/>
I tried to address this issue several times in the last weeks, well, without much success.
...
So, whatever we decide, I'm -1 on duplicating the block code.
My problem with the blocks code is that reusing the 2.1 blocks code would force people to make blocks upwards-compatible, slowing down transitioning between old- and new-style blocks.
...
Let me try to make a synthesis and proposal :
1 - creating a 2.2 repository is necessary to start working while still be able to issue 2.1.x maintainance releases,
2 - copying all blocks to the 2.2 repo is not wanted since not all blocks will evolve in the 2.2
3 - the "real blocks" may require some modifications of the current "fake blocks".
So what about the following (somewhat already expressed, BTW) :
- start a 2.2 repo with only the Cocoon core (i.e. src/java)
- copy blocks in the 2.2 repo only if they require substantial changes that would break the ability to quickly do a 2.1.x release.
- have an intelligent 2.2 build that gets missing blocks from the 2.1 (IIRC Carsten talked about it)
- backport to the 2.1 non disruptive enhancements/bug fixes appearing in the 2.2 repo
+1 let's give it a shot. This is probably what Carsten was picturing all along. :)
+1 as well. the magic "build script that gets missing blocks from 2.1" would simply be a cvs checkout, followed with a few file copy operations.
About blocks, we can envision that some block evolutions can happen into the 2.2 repo and, if back-compatible, be fully copied back to the 2.1. In that case, the block would be removed from the 2.2 repo, until a new evolution cycle comes again on that block.
ok
The only problem is if "real blocks" require to modify the directory structure of blocks. I'm not sure of this, as I mostly envision it as an augmentation of the current structure, e.g. with a new "web" directory that would contain the block's sitemap and resources.
I don't think this will be necessary - at least Stefano certainly didn't seem to think it necessary because he was planning on doing all this right in 2.1.
After a little more thinking, I think that we should avoid placing block code in cocoon-2.2 alltogether because we need to start talking about the 'community process' of accepting new blocks, where they fit, how they get 'certified' and all these things.
So, I agree: let's make cocoon-2.2 and keep all the block code out for now (the build process can construct the code from the cocoon-2.1 repository.
This leaves open a single question: where do we put the various block.xml descriptor files? I would say cocoon-2.1 for now and later moved them into a new cocoon-blocks module.
What do you think?
-- Stefano.