On 26 Apr 2007, at 13:20, Jörg Schaible wrote:
Hi Jason,
Therefore the slots. The project itself can introduce them, if two
major versions can be used at same time. Think about a hypothetical
commons-logging 2.0 (it is discussed) that might have a different
API. I am quite sure Jakarta folks will ensure that 2.x and 1.x
series can be used at the same time - simply because even in the
Maven repo itself ~ 2000 artifacts depend on it. Without something
like the slots, you will never be able to create a new Maven-based
project using JCL 2.x ...
Well kick me if I am wrong, but is this not where well managed
projects use deprecation and wrappers around the new code to work
from the old API?
I know plexus and classworlds are trying to for backwards compatibility.
What rule states that commons-logging 2.0 cannot contain the api from
commons-logging 1.0 with deprecated marks? I doubt that everytime
someone wants to change their API they would much rather do that than
make a mutually exclusive, thusly cohabitable, API for the new version.
Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]