I mean that in version 10.2 we document that "in version 10.3 (or 10.4)
of Derby, we will no longer support environments where multiple versions
of Derby are available in the same classloader."
Then in version 10.3 (or 10.4) if/when someone sends an email saying
"I've got this weird bug where upgrades don't seem to have any impact"
or "when I upgrade I'm getting weird exceptions about methods not being
found" we can say "run this tool (some form of sysinfo that works with
classloaders)" and if it shows they have mixed versions we can say
"don't do that, here are instructions on how to not do that" instead of
"let's try to fix this."
David
Francois Orsini wrote:
Hi David,
What does it mean to "deprecate" support of
mixed client/embedded version environments in 10.2, and officialy remove
support in 10.3 or 10.4?
If you could be a little more specific that would be great.
Thanks,
--francois
On 11/2/05, *David W. Van Couvering* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Not only in our discussions, but in the coding I am doing, ensuring
forward and backward compatibility in mixed version environments is
achievable but fairly onerous.
I think there has been some discussion of this, but I wanted to make it
a more direct question: is it possible that we "deprecate" support of
mixed client/embedded version environments in 10.2, and officialy remove
support in 10.3 or 10.4? This would reduce the overhead of
adding/supporting common code significantly. But I am not in support
and I am not clear of the impact of doing this.
Thanks,
David
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
