cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: on better release and version management
Date Fri, 19 Sep 2003 13:39:29 GMT

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.


Mime
View raw message