Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <495CCAD0.9000605@kippdata.de>
Date: Thu, 01 Jan 2009 14:53:20 +0100
From: Rainer Jung <rainer.jung@kippdata.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de;
 rv:1.9.1b3pre) Gecko/20081204 Thunderbird/3.0b1
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: tcnative API stability/compatibility
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8bit

Hi,

we now have tcnative 1.1.x and trunk. What's our goal w.r.t. API stability?

Citing from an earlier thread:

>> > we do have a 1.1.x branch in tcnative which is supposed to be the stable
>> > brach.
>
> Ok. I thought this was still also used in 6.0. OTOH, the library should
> be renamed so that both v1.1 and this new incompatible one could be used
> at the same time, right ?
>
> R�my

We have native and Java code in tcnative. I guess we are talking here 
mainly about the Java side, i.e. the native one is the implementation, 
which is only exposed via the Java code and the Java code represents the 
API we do make public.

I expect we want the following situation:

- new methods can be added to tcnative trunk

- old methods are not allowed to be removed either from trunk or from 1.1.x

   Trunk will most likely result in 1.2.x versions, and code using 
tcnative should be able to update from 1.1 to 1.2 without 
incompatibilities. Otherwise we would already now decide, that trunk 
will become a 2.x.
   Methods could get deprecated in trunk though.
   Exception: There are some methods which wouldn't have worked any time 
in the past, because they refer to native functions that don't exist. I 
think it is a good cleanup to remove/rename them now in trunk and 1.1.x.

Anyone fine with that?

Concerning the native side. What is the compatibility goal between the 
Java code and the native lib? Do we want to urge each using software to use

a) exactly the same version of native, than the version of the Java code
b) the same minor version, but patch version greater or equal to the 
Java side
c) the same major version and any minor/patch greater or equal ...

I guess we want a) or b), I think it's to early for c).

If we go for b) and trunk is for a 1.2.x version, we don't need to 
support loading multiple copies of the native library. So I guess, b) is 
what we should do?

Regards,

Rainer


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org