cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <>
Subject Re: on better release and version management
Date Fri, 19 Sep 2003 13:05:52 GMT
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. :)

> 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.

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.


View raw message