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.
Agreed.
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 features.
-- Stefano Mazzocchi <[EMAIL PROTECTED]> Pluralitas non est ponenda sine necessitate [William of Ockham] --------------------------------------------------------------------
