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. :)
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.
Geoff
