Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (athena.apache.org: domain of akarasulu@gmail.com
 designates 209.85.132.250 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=BHKgDNaovZYJ6HWM0Q/ZfjfqIROeallc6FC0c6lIIZ5SiGGq+a62m9FrCqAINchN9b
         MmGs7C1IJgccihvYqrG8xyfWgQUlm7MslYKc/YITXpN888czAqzw0d+pjmaOoVcruDLW
         IxDHyfx6xwMV5warXPPJ/FbXaLboWo0gvK8eo=
MIME-Version: 1.0
In-Reply-To: <4A817D74.6020101@nextury.com>
References: <a32f6b020908110604s393415a2t48b993a77b2ba0f@mail.gmail.com>
	 <a43524d00908110620j13c8578au7e38a1e6e6d9b8ad@mail.gmail.com>
	 <4A817360.2030406@nextury.com>
	 <a32f6b020908110654u646c98e0i3d73ff21de64ccfa@mail.gmail.com>
	 <4A817D74.6020101@nextury.com>
Date: Tue, 11 Aug 2009 17:23:51 +0300
Message-ID: <a32f6b020908110723s65eee60eu9d4397c2b27ec426@mail.gmail.com>
Subject: Re: [ApacheDS] How about yet another versioning scheme conversation
	gang?
From: Alex Karasulu <akarasulu@gmail.com>
To: Apache Directory Developers List <dev@directory.apache.org>
Content-Type: multipart/alternative; boundary=0016e643531e982e300470de7314

--0016e643531e982e300470de7314
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, Aug 11, 2009 at 5:17 PM, Emmanuel Lecharny <elecharny@apache.org>wr=
ote:

> Alex Karasulu wrote:
>
>> I think we're on the same page.  But I would add one more caveat, that Y
>> "tries" to maintain API compatibility but there is no guarantee.
>>
> Why can't we guarantee that if the API is changed, then the old API will
> still be available, but marked as @deprecated, until the next X release ?=
 Is
> it too strong a constraint?
>

Yeah I think it is too much.  Not feeling too generous on the API front
since it's going to see lots of flux.  Don't want our hands tied like it wa=
s
during all these 1.0/1.5 branches.  I want to move faster.  The faster we
move we can come back in like 3.0 and say Y can guarantee API backwards
compatibility.


>
> There is also an aspect which is not related to the API : configuration
> _and_ data. For Minor versions, we must guarantee a compatible
> configuration, and a compatible dataBase, otherwise we -at least- must
> provide teh tooling to migrate easily both of them.
>
> Thoughts ?
>

I'm not willing to guarantee this.  Technically the database format and the
configuration format/scheme is yet another interface the user is faced with
regarding ADS.  When I say interface I mean it very broadly to include data
formats and things like configuration.

I might want to slowly migrate some configuration feature that was in the
XML format slowly over two feature releases into ADS.  If I must provide
this guarantee then I have to wait until 3.0 to introduce these changes.
It's not a good thing for us who really want to provide the user with what
they really need in the end as soon as possible.

We must allow for rapid progression. Like I said I will be willing to make
the guarantee once we're in a 3.0 or 4.0.  But not now.  Life is hard enoug=
h
for us already.  Let's keep the load light and help users when and if there
really are API issues in the end.  But it's safer to say we provide no
guarantee than to say that we do guarantee back compat.

Let's just

--
cordialement, regards,
Emmanuel L=E9charny
www.iktek.com
directory.apache.org


--=20
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org

--0016e643531e982e300470de7314
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Tue, Aug 11, 2009 at 5:17 PM, Emmanue=
l Lecharny <span dir=3D"ltr">&lt;<a href=3D"mailto:elecharny@apache.org">el=
echarny@apache.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt =
0.8ex; padding-left: 1ex;">
<div class=3D"im">Alex Karasulu wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I think we&#39;re on the same page. =A0But I would add one more caveat, tha=
t Y<br>
&quot;tries&quot; to maintain API compatibility but there is no guarantee. =
<br>
</blockquote></div>
Why can&#39;t we guarantee that if the API is changed, then the old API wil=
l still be available, but marked as @deprecated, until the next X release ?=
 Is it too strong a constraint?<br>
</blockquote><div><br>Yeah I think it is too much.=A0 Not feeling too gener=
ous on the API front since it&#39;s going to see lots of flux.=A0 Don&#39;t=
 want our hands tied like it was during all these 1.0/1.5 branches.=A0 I wa=
nt to move faster.=A0 The faster we move we can come back in like 3.0 and s=
ay Y can guarantee API backwards compatibility.<br>
=A0</div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid =
rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
There is also an aspect which is not related to the API : configuration _an=
d_ data. For Minor versions, we must guarantee a compatible configuration, =
and a compatible dataBase, otherwise we -at least- must provide teh tooling=
 to migrate easily both of them.<br>

<br>
Thoughts ?<div><div></div><div class=3D"h5"></div></div></blockquote><div c=
lass=3D"h5"><br>I&#39;m not willing to guarantee this.=A0 Technically the d=
atabase format and the configuration format/scheme is yet another interface=
 the user is faced with regarding ADS.=A0 When I say interface I mean it ve=
ry broadly to include data formats and things like configuration.<br>
<br>I might want to slowly migrate some configuration feature that was in t=
he XML format slowly over two feature releases into ADS.=A0 If I must provi=
de this guarantee then I have to wait until 3.0 to introduce these changes.=
=A0 It&#39;s not a good thing for us who really want to provide the user wi=
th what they really need in the end as soon as possible.<br>
<br>We must allow for rapid progression. Like I said I will be willing to m=
ake the guarantee once we&#39;re in a 3.0 or 4.0.=A0 But not now.=A0 Life i=
s hard enough for us already.=A0 Let&#39;s keep the load light and help use=
rs when and if there really are API issues in the end.=A0 But it&#39;s safe=
r to say we provide no guarantee than to say that we do guarantee back comp=
at. <br>
<br>Let&#39;s just<br><br>
--<br>
cordialement, regards,<br>
Emmanuel L=E9charny<br>
<a href=3D"http://www.iktek.com" target=3D"_blank">www.iktek.com</a><br>
<a href=3D"http://directory.apache.org" target=3D"_blank">directory.apache.=
org</a><br>
<br>
<br>
</div></div><br><br clear=3D"all"><br>-- <br>Alex Karasulu<br>My Blog :: <a=
 href=3D"http://www.jroller.com/akarasulu/">http://www.jroller.com/akarasul=
u/</a><br>Apache Directory Server :: <a href=3D"http://directory.apache.org=
">http://directory.apache.org</a><br>
Apache MINA :: <a href=3D"http://mina.apache.org">http://mina.apache.org</a=
><br><br>

--0016e643531e982e300470de7314--