Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 94906 invoked from network); 30 Oct 2006 09:28:02 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 30 Oct 2006 09:28:02 -0000 Received: (qmail 11816 invoked by uid 500); 30 Oct 2006 09:28:13 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 11571 invoked by uid 500); 30 Oct 2006 09:28:12 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 11560 invoked by uid 99); 30 Oct 2006 09:28:12 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 30 Oct 2006 01:28:12 -0800 X-ASF-Spam-Status: No, hits=2.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of trustin@gmail.com designates 64.233.162.192 as permitted sender) Received: from [64.233.162.192] (HELO nz-out-0102.google.com) (64.233.162.192) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 30 Oct 2006 01:27:59 -0800 Received: by nz-out-0102.google.com with SMTP id z3so1087887nzf for ; Mon, 30 Oct 2006 01:27:38 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=OvSmWHAbnB4bWx5UYlO/GZeUIxB0Aj+lyNf0uUSoRyheeZa3qgn87YtXoZ3zZ4x2OF4ywkRYQzpQwiXu9/9DLNPuZbOG4g110Jv2+3g3Vn9LdK6MoLZA3ozHI0bQNxHIH5qJdyXPiDrGfSq4KMD/wWRGKqyWM8G4RnvJHWTToA0= Received: by 10.35.27.1 with SMTP id e1mr4547038pyj; Mon, 30 Oct 2006 01:27:38 -0800 (PST) Received: by 10.35.68.13 with HTTP; Mon, 30 Oct 2006 01:27:38 -0800 (PST) Message-ID: <768dcb2e0610300127l48b4ff7bh45b30b228de4c2f9@mail.gmail.com> Date: Mon, 30 Oct 2006 18:27:38 +0900 From: "Trustin Lee" To: "Apache Directory Developers List" Subject: Re: MINA Trunks & ADS In-Reply-To: <45428E3B.6080303@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_28083_4179074.1162200458525" References: <768dcb2e0610222236t65f60765p23ffe53977f92726@mail.gmail.com> <4541A287.3070900@gmail.com> <45421357.7010605@bellsouth.net> <454289BE.5040609@bellsouth.net> <45428E3B.6080303@gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_28083_4179074.1162200458525 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 10/28/06, Emmanuel Lecharny wrote: > > Alex Karasulu a =E9crit : > > > Emmanuel Lecharny wrote: > > > >> Using externals or using dependencies are two possibilities. My point > >> was only to prevent project building breakage. > >> > >> Btw, I was just wondering if it would not have been better to simply > >> deprecate the removed class and method of MINA 1.0 instead of > >> removing them. What is the "politic" regarding such modifications ? > > > > > > Hmmm what specifically were you referring to? A class was removed in > > MINA 1.0? > > No, a class and some methods were removed in mina trunks. > > > > > Basically up to 1.0 anything goes. But after 1.0 there should be a > > deprecation policy in effect. I don't know how the MINA folks are > > working that. > > ok, I think we agreed on that. Let's ask MINA's guys :) Even though we reached to 1.0, we are still in course of redesigning API. Therefore, please stick to 1.0 branch. It's feature complete and fits perfectly to LDAP and other related protocols. Trustin --=20 what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP key fingerprints: * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6 ------=_Part_28083_4179074.1162200458525 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 10/28/06, Emmanuel Lecharny <elecharny@gmail.com> wrote:
Alex Karasulu a =E9crit :

> Emmanuel Lecharny wrote:
>
&= gt;> Using externals or using dependencies are two possibilities. My poi= nt
>> was only to prevent project building breakage.
>>
>> Btw, I was just wondering if it would not have been better to = simply
>> deprecate the removed class and method of MINA 1.0 inste= ad of
>> removing them. What is the "politic" regarding = such modifications ?
>
>
> Hmmm what specifically were you referring to? = ; A class was removed in
> MINA 1.0?

No, a class and some= methods were removed in mina trunks.

>
> Basically up to 1= .0 anything goes.  But after=20 1.0 there should be a
> deprecation policy in effect.  I do= n't know how the MINA folks are
> working that.

ok, I think we= agreed on that. Let's ask MINA's guys :)

Even though = we reached to=20 1.0, we are still in course of redesigning API.  Therefore, please sti= ck to 1.0 branch.  It's feature complete and fits perfectly to LDAP an= d other related protocols.

Trustin
--
what we call hu= man nature is actually human habit
--
http://gleamynode.net/
= --
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41  4A29 5= 44D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4  455E 1C62 A7DC = 0255 ECA6 ------=_Part_28083_4179074.1162200458525--