cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Stabilizing flow in order to release
Date Tue, 04 Mar 2003 10:43:36 GMT
Sylvain Wallez wrote:

> I'm not so strict about that : refer to my answer to Christopher : we 
> need some *optional* stuff like that one to lower the entry cost to 
> people that are not used to "programming in the large" (especially 
> non-large projects).
> Leaving a bit the purely technical matters, having such RAD features is 
> also good when you want to convince people having a {AS,JS,PH}P 
> background to migrate to Cocoon or for training sessions where the 
> available time - or trainees knowledge - doesn't allow the deployment of 
> a full-featured O/R tool for hands-on exercises.

Very good points. I now agree that having something so simple might be 
useful for providing migration paths, but only if we understand that we 
must make those migration path *continue* to more architecturally 
advanced solutions.

>>                                     - o -
>> This said, let me write down a list of things that have to happen 
>> before we can safely consider the flow ready for release:
>> 1) Sylvain's complains about the abuse of the Environment must be 
>> resolved. 
> I'm happy to see that as the main priority ;-)
>> 2) each and every single FOM (Flow Object Model) object, method and 
>> property must be documented and then voted upon.
> Agree. We also have to find a solution for "flow blocks" so that flow 
> features can be augmented without interfering with the main trunk.


>> 3) no higher level functionality should be added without a previous 
>> RT/proposal/vote cycle.
>> I'm perfectly aware of the fact that this will reduce the freedom of 
>> people like Chris to innovate and show potentially creative new uses 
>> of the flow. For this reason I'd add that:
>> 4) everybody is allowed to write flow-related stuff in the scratchpad 
>> without the previous RT/proposal/vote cycle, even if they are strongly 
>> encouradged to do so anyway to foster communication and creative 
>> discussion.
> Being able to structure flow (or JS ?) features in blocks is IMO the key 
> for having a stable foundation without discouraging creativity.

True. I'm all ears on how this can be achieved. Chris? any idea?

>> Anyway, the point I want to come across is the following:
>> Cocoon is committed to provide a solid foundation for people to work 
>> and operate. Currently, Cocoon 2.1-dev is alpha, means that we can 
>> change things around without noticing and without allowing people to 
>> complain because we warned them and we want to have the complete 
>> freedom to innovate.
>> At the same time, Cocoon 2.1-dev has to reach beta state ASAP since we 
>> are nearly feature complete and our internal cleanups and refactoring 
>> are working very well. [in a followup I will outline what's missing 
>> before release] 
> C2.1 isn't even alpha ! 

wrong. Read WARNING.txt.

> We should first issue some alpha releases to 
> show people that stabilization is on the way and they can start looking 
> at it and even using it. 

-1, we've never released alpha stuff and I don't see why we should start 
now. If you want to play with it there's CVS and everybody using 2.1-dev 
got it from there and having read WARNING.txt knows what they're doing.

> This will drain comments and help use to 
> strengthen the beta version.

That's what beta versions are for: we don't 'guarantee' complete 
back-compatibility from beta to final because beta is meant to be a way 
to get feedback, but we state that we 'froze' the build and we aim to 
polish things until we are *positive* about back compatibility of our 

Stefano Mazzocchi                               <>
    Pluralitas non est ponenda sine necessitate [William of Ockham]

View raw message