cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: 2.1.8 (Was: Re: JING Transformer...)
Date Wed, 31 Aug 2005 17:20:45 GMT
Mark Lundquist wrote:

> On Aug 31, 2005, at 9:27 AM, Ralph Goers wrote:
>     My opinion is that a community that releases software that it
>     won't stand behind has a significant problem.
> "Won't stand behind" seems like too strong/loaded of a 
> characterization for this CForms thing. Support for CForms has been 
> great.

Yes - you are correct.  I didn't mean to imply that the folks working on 
CForms have not been there to support the user base.  I actually 
consider it one of Cocoon's greatest successes.

> Here's what I think "stable" means, can somebody please 
> confirm/correct this?:
> /"X is stable" entails that:
> (1) Support for X will not be unduly removed, i.e. without going 
> through the deprecation cycle. "Support" entails that product releases 
> will include X, and that the product will not be released with changes 
> that are known to break X.
> (2) All future changes to X's APIs will be backward-compatible.
> /

We don't guarantee backward-compatibility forever, so 2 is only accurate 
when taken in the context of number 1.

> Your position is that CForms is "good enough", and we should just mark 
> it as "stable" and have done with it. Because for you, any "good 
> enough" CForms is better than no CForms, which is what you get as long 
> as it's still "unstable", thanks to your employer's bull-headed, 
> inflexible policy.

Well, I wouldn't say CForms is better than none.  I'd say it is pretty 
damn good as it is.

I doubt I work for the only inflexible employer in the world. Actually, 
I might be more inflexible than them, because, as you put it, it is a 
PITA for me. Also, I am also the one who would have to explain why they 
cannot simply upgrade from release 2.1.8 to 2.1.9 and it makes me look bad.

> But for my part... I do not want to be stuck with a "better than none" 
> CForms forever. I want CForms to be /right/ eventually, and I don't 
> want anything closing the door to that. There are still things that 
> need to be done to get it there. And until then, I get to use an 
> "almost right" CForms, because I don't have anybody telling me what I 
> can and can't use.

Products evolve. Products that don't, die. One should expect that CForms 
will evolve as well. It is the natural process.  However, an unstable 
block can evolve in unstable ways - or be thrown away entirely.  On the 
other hand, a stable block will evolve in a more controlled 
environment.  We all know this already.

> I certainly do not think that saying "we still have more work to do 
> before we promise that there will never be a backwards-incompatible 
> API change" constitutes "not standing behind" our product. Quite the 
> contrary, I think it represents a greater commitment than just "close 
> the lid and flush" :-/

By "not standing behind" I simply mean not caring what impact a change 
might have on the user base.  The point I'm making is I believe we are 
already to the point where we would not introduce backwards-incompatible 
changes in CForms without careful consideration.  In other words, I 
believe we are already standing behind CForms but for some reason just 
don't want to admit it.

> cheers,
> —ml—

View raw message