cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Sayre" <>
Subject Re: FOM blocking 2.1 release
Date Sun, 15 Jun 2003 02:19:18 GMT
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.

View raw message