cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [proposal] rethinking distribution strategy
Date Mon, 14 Apr 2003 08:38:40 GMT
on 4/14/03 9:14 AM Niclas Hedhman wrote:

> On Sunday 13 April 2003 01:00, Stefano Mazzocchi wrote:
>>on 4/12/03 5:03 PM Geoff Howard wrote:
>>>I'd be for it - but what about bugs marked blocking 2.1 release?  And
>>>what about pending major changes to central contracts (flow)?
>>>How do we avoid getting stalled in beta?
>>by releasing early and often, fixing one issue at a time :-)
> Additionally,
> The "Release Early, Release Often" seems to be inversely to the size of the 
> project to be released. Initially it works well, and as the project grows, 
> things are released less and less often, due to fear of "contract failures".
> This can easily be alleviated by breaking up the release cycles for each part, 
> especially now when blocks and modules are becoming a reality.
> One could also require that "Core 2.n" is compatible with "Module X ver 
> 2.(n-1)" and "Block Y ver 2.(n-2)", for faster and phased (not all in one 
> bang) introduction of core features.

Niclas, you are always late :-)

All this is planned for Cocoon 2.2 when hotdeployable blocks will make
it possible to separate all the things we have now in /src/blocks into
separate modules with totally separate release cycles.

I expect that to make a huge change on how things move on around here.

But in order to do 2.2, we will need substantial architectural changes
and this will very likely require a new release, potentially even a 3.0
one, depending on how much the avalon contracts needs to be updated. I
still don't know.

Anyway, the build system I introduced went exactly in this direction,
but nothing more than this can be done without opening up the entire
component-loading architecture and this was even too painful to think
before a major release.


View raw message