cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: on better release and version management
Date Fri, 19 Sep 2003 12:47:45 GMT
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.
>> 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 Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message