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—
