Carsten Ziegeler wrote:
<snip type="happy agreement"/>
I tried to address this issue several times in the last weeks, well, without much success.
One thing I want to stress again: *if* we would make a new repository
for 2.2 and duplicate all code, this would include the blocks as well.
So we would not only end up with the two versions to maintain for the core
but for each and every block as well! And this makes imho no sense. It's ok for the core, if we say 2.1 is only bug-fixing from now on. But it makes absolutely no sense for blocks. I think the development of blocks should be independent from the
development of the core. With duplicating the code we loose this.
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.
During the Hackathon on the 6th, I will be busy with GT preparations, so I won't be able to participate much with the discussions. :-( Anyway, please be assured that Bruno and I discussed the aspect of compatibility at length, and IIRC Bruno has been jotting down notes for this bound-to-be-happening IRL discussion. I don't think that we can 1) require 2.2 compatibility by all blocks, since some of them are only worked on by a few people, and 2) we should hinder progress on 2.2 blocks by requiring them to be stuck in the 2.1 repository. I know that we will try and do our best to keep the 2.1 version of Woody in a sane state after 2.2 development starts, most probably also backporting new things that happen along the 2.2 'branch'. Still, we want a freeway for 2.2 development, should the need arise.
Does that help? Or do I misunderstand your view on this matter?
(me being happy to at least being able to contribute _something_ this days)
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
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.
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.
What do you think ?
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
