I agree we need to address client/server compatibility, but my hope is
that this is addressed by defining the appropriate stability levels for
the interfaces that the client depends upon. I am guessing this
includes DRDA, the metadata stored procedures, and probably some others.
So when you look at the interface list, make sure (a) every interface
the client depends upon is called out and (b) that these interfaces are
declared as Stable or Private Stable (a new classification I just added).
I think even after a major release we should strive for backwards
compatibility with clients. However, if we *do* need to make an
incompatible change (God forbid) then we would need to make it at a
major release and document clearly the incompatible change.
David
Kathey Marsden wrote:
Daniel John Debrunner wrote:
David W. Van Couvering wrote:
Hi, all. I would like to propose that we have a discussion, in
preparation for (at some time in the future) a vote on the interface
table I put together at
http://wiki.apache.org/db-derby/ForwardCompatibility
I think we need something about client/sever compatibility. How long
will different client/sever combinations be supported? When will we
negotiate down vs throw an error? The same questions apply for
client/server differences in jvm version. Should that information be
on a different page or this one? I prefer a timed based support (e.g.
five years) rather than a decision based on Derby versions.
Kathey
