This is my first post to the list, but I've been lurking for quite a while.
> you can mark it as beta as much as you like, but people are going to > discover it, fall in love with it, use it for testing, then pressured > by their bosses, put it in production, then ask support for it, or at > least a back compatibility layer. You could put the word "beta" in the package hierarchy, and then change it when the FOM solidifies. That would be pretty clear. > > Do you really want to force our users to go thru this? I don't. > > Cocoon is highly respected for its contract solidity. > > At the same time, I don't want to block the release further. So there > is the plan: > > 1) I will try to patch the FOM for the proposed plan for June 24th. > > 2) If I can't do it, we release with what we have and we state loud > and > clear that the FOM contract should be considered unstable and that > might change in future releases. I'd advocate leaving full access, while making it clear that such access is unsupported and not subject to any contract (I'm thinking of something like SLOT-VALUE access in Lisp, where use from outside the object signals a violation of the author's intent, but is none the less allowed). Perhaps this approach would spur more innovation than limiting it from the outset. Maybe allow full access in implementation classes but commit only to an interface that allows a limited subset of that functionality. I've only been following/using Cocoon for approx 3 months, so it's quite possible that this approach has already failed you, but I thought I would throw it out there.
