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—
Ralph
