cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Lundquist ...@wrinkledog.com>
Subject Re: 2.1.8 (Was: Re: JING Transformer...)
Date Wed, 31 Aug 2005 17:45:27 GMT

On Aug 31, 2005, at 10:20 AM, Ralph Goers wrote:

> 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.

Indeed.

However, that's not the definition of "stable" that we are working 
under.  Apparently, for us "stable" means that there won't be any API 
changes that break backwards-compatibility.

I wonder if some compromise approach might work, though.  I can imagine 
a couple, here are my brain-farts:

1) Come up with a new term other than "stable" to mean "guaranteed no 
future backwards-incompatible API changes", and redefine "stable" to 
the meaning suggested by your mail (excerpted above).  This of course 
is to allow "unstable" to mean the opposite of that, instead of the 
opposite of what "stable" means today... :-)

Or...

2) Aim for "2.1 stability".  The idea is to expedite the stabilization 
of CForms in 2.1.x, while leaving it "unstable" in 2.2.  (N.B., I am 
not suggesting breaking synchronization of trunk and BRANCH_2_1_X 
w.r.t. the forms block... I'm talking only about the block metadata).  
I dunno, maybe we would even canvas the Cocoon community to find out 
what features/fixes float to the top of the list.  Then, focus in, 
knock down that short list and pronounce it stable in 2.1.8 or 
whatever.  Meanwhile, CForms is still free to be changed as necessary 
in 2.2 to get it "really right".  The rationale is that for users to 
upgrade from 2.1 to 2.2 is going to entail some changes, block 
stability notwithstanding.

WDY/OT?
—ml—

Mime
View raw message