Reinhard Poetz wrote:
The current situation is that the implementation (runs in many
projects) and the community (large developer and user community) are
stable, but the interfaces are *not*. I tried to express this with the
hypothetical block descriptor fragment:
<state
community="stable"
interfaces="unstable"
implementation="stable"/>
I don't want to mark Cocoon Forms as stable if we *know now* that the
interfaces will change. Marking Cocoon Forms as stable would require
us to support them and we would create a lot of confusion in the
future (e.g. the different Form APIs which are confusing enough now).
The problem is that we are recommending (and have been recommending)
CForms as our forms framework for a long time. Even if you haven't
marked it stable, it already should be, based upon those recommendations.
In other words, my +1 depends on a rewritten Flowscript API and
repeater binding. As long as nobody does the actual work we will have
to live with an "unstable" Cocoon Forms block. (though, if the
majority of the Cocoon committers wants to mark it as stable *now* I
won't/can't stop it but expect my -1 to express my concerns and a lot
of "I've told you so" in the future ;-) )
I would prefer that CForms be marked stable unless the necessary work
can be done in the next 6 weeks. Just so you know, I will be requiring
a stable CForms on the next Cocoon release or I will vote -1.
Ralph
