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 Thu, 11 Sep 2003 11:42:31 GMT
Reinhard Poetz wrote:
>>From: Bruno Dumon
>>>Carsten made a good proposal how we can continue having 3 
>>>and how this can be done with only little code duplicating: 
>>>I'm +1 with his proposal - the reason is simple: Some people (and 
>>>customers too!) asked me if we have gone crazy and how they 
>>can update 
>>>Cocoon in the future without being alpha/beta-tester for 
>>'real' blocks 
>>>and Fortress. We *must* be able to maintain 2.1 without all new 
>>>features like blocks and Fortress because IMNSHO these steps are to 
>>>big for 2.1 and I'm -1 on the changes in the current repository.
>>I'm also +1 for starting a new repository, but I don't like 
>>Carsten's proposal that much. I'd rather see the entire 
>>repository duplicated, and move all development effort to the 
>>2.2 repository. Only bugfixes should be applied to the 2.1 
>>repository, and occasional backports of new functionality if 
>>anyone wants to.
> Let's look which new features are planned for the next time and when
> they will be ready for beta and for final release?
>  - real blocks
>  - virtual sitemap components
>  - intercepted flowscript
>  - use Fortress as container
>  - Cocoon Forms (aka Woody)
>  - Cocoon Portals (new portal block)
> IMO the first four items should be part of 2.2 but the two last items
> should be released earlier. Let's assume a szenario that the
> implementation of them takes very long (e.g. more than a year until we
> reach a stable version). Do you really want to wait with Cocoon Forms
> and Cocoon Portals such a long time (not to mention the many other
> blocks)? You can say now that you develop under 2.2 and you do
> occasional backports but IMO the problem is that e.g. Cocoon Forms is
> tested with 2.2 but NOT with 2.1 and we say that 2.1 is our stable
> branch! Additionally we get a great mess with all our blocks if they are
> duplicated, some are backported, some not and we developers have to do a
> lot of work twice, work which is not real fun.
> That's the reason why I'm +1 with Carstens proposal:
>  - 2.1 repository containing all our blocks
>  - 2.2 repository contains only the new stuff introduced by the first
>        four points from above
>  - the 2.2 build mechanism is 'clever' enough to get all sources
>    from 2.1 that are missing

I am undecided but something occurred to me in the shower this AM which 
made me wonder whether Carsten's proposal will work.  As blocks evolve 
into real blocks, the changes will need to happen right in the 
src/blocks.  Can we guarantee (or will it be too painful to ensure) that 
all changes will be back-compatible with 2.1?  IOW, we will soon start 
having new configurations, etc. moving into the blocks source, possibly 
shuffling around of dir structure and probably deprecating some things 
currently necessary (like some of the configuration patching).  Just 
thinking out loud...


View raw message