Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Mime-Version: 1.0 (Apple Message framework v622)
In-Reply-To: <4315E6ED.2010507@dslextreme.com>
References: <251B34B1-3E0B-45CC-B0A3-6CD947ADED42@betaversion.org>
 <4314907B.8050501@reverycodes.com> <43149AB7.3080509@dslextreme.com>
 <4314A036.80605@reverycodes.com>
 <4D0D0562-D410-4277-8E1E-D8E31361AF3E@betaversion.org>
 <4315CE90.3010406@dslextreme.com> <4315D60B.6030504@reverycodes.com>
 <4315DA77.5070603@dslextreme.com>
 <06dbf9fd764f1cc8f52f089d6936b5fd@wrinkledog.com>
 <4315E6ED.2010507@dslextreme.com>
Content-Type: multipart/alternative; boundary=Apple-Mail-6--973243698
Message-Id: <42fd1ece7295bae85a0689e288902349@wrinkledog.com>
From: Mark Lundquist <ml@wrinkledog.com>
Subject: Re: 2.1.8 (Was: Re: JING Transformer...)
Date: Wed, 31 Aug 2005 10:45:27 -0700
To: dev@cocoon.apache.org


--Apple-Mail-6--973243698
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=WINDOWS-1252;
	format=flowed


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=20=

> would not introduce backwards-incompatible changes in CForms without=20=

> careful consideration.

Indeed.

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

I wonder if some compromise approach might work, though.  I can imagine=20=

a couple, here are my brain-farts:

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

Or...

2) Aim for "2.1 stability".  The idea is to expedite the stabilization=20=

of CForms in 2.1.x, while leaving it "unstable" in 2.2.  (N.B., I am=20
not suggesting breaking synchronization of trunk and BRANCH_2_1_X=20
w.r.t. the forms block... I'm talking only about the block metadata). =20=

I dunno, maybe we would even canvas the Cocoon community to find out=20
what features/fixes float to the top of the list.  Then, focus in,=20
knock down that short list and pronounce it stable in 2.1.8 or=20
whatever.  Meanwhile, CForms is still free to be changed as necessary=20
in 2.2 to get it "really right".  The rationale is that for users to=20
upgrade from 2.1 to 2.2 is going to entail some changes, block=20
stability notwithstanding.

WDY/OT?
=97ml=97

--Apple-Mail-6--973243698
Content-Transfer-Encoding: quoted-printable
Content-Type: text/enriched;
	charset=WINDOWS-1252


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


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

</excerpt>

Indeed.


However, that's not the definition of "stable" that we are working
under.  Apparently, for us "stable" means that there
<italic>won't<bold> </bold></italic>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 <italic>only</italic> 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 <italic>is</italic> going
to entail some changes, block stability notwithstanding.


WDY/OT?

=97ml=97


--Apple-Mail-6--973243698--