Deprecating support for mixed client/server version environments?

["David W. Van Couvering" <Da...@Sun.COM>]

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

Re: Deprecating support for mixed client/server version environments?

[Francois Orsini <fr...@gmail.com>]

On 11/2/05, David W. Van Couvering <Da...@sun.com> wrote:
>
> 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."


I thought we would still allow that as long as version compatibility allows
it? do we want to completely prevent users from running different versions
of Derby 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."


I guess the expanded 'sysinfo' you're talking about would be something we
could run against a remote Derby instance or against the same JVM? Are you
thinking of having such utility running within a separate classloader of its
own _or_ interact with other classloaders in order to find out what versions
of Derby are running in a particular JVM?

Regarding the instructions on how to not do that - are you thinking of
suggesting the users to run the different versions of Derby in separate
classloaders?

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* <David.Vancouvering@sun.com
> > <ma...@sun.com>> 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
> >
> >
> >
> >
>
>
>

Re: Deprecating support for mixed client/server version environments?

["David W. Van Couvering" <Da...@Sun.COM>]

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* <David.Vancouvering@sun.com 
> <ma...@sun.com>> 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
> 
> 
> 
> 

Re: Deprecating support for mixed client/server version environments?

[Francois Orsini <fr...@gmail.com>]

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 <Da...@sun.com> 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
>
>
>
>

Re: Deprecating support for mixed client/server version environments?

["David W. Van Couvering" <Da...@Sun.COM>]

Ok, thanks Kathey, I will hold off.  I really wanted to understand what 
the impact was, I was not intending to push this at all.

David

Kathey Marsden wrote:
> David W. Van Couvering wrote:
> 
> 
>>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?  
> 
> 
> I think  an upgrade in a clustered environment where you need to upgrade
> all the servers and then all the clients that was discussed in DERBY-289
> is addressed by your documented approach but I don't know what the
> solution would for upgrade would be  if compatibility was removed
> entirely.  Can I ask you please to be merciful and hold off  on this
> proposal until sometime in 10.3 while we recover from what has already
> been proposed in terms of behaviour changes?    If what you have
> already  proposed goes  through it is  going to be painful enough for
> this round in my humble opinion.
> 
> Kathey
> 
> 

Re: Deprecating support for mixed client/server version environments?

[Kathey Marsden <km...@sbcglobal.net>]

David W. Van Couvering wrote:

> 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?  

I think  an upgrade in a clustered environment where you need to upgrade
all the servers and then all the clients that was discussed in DERBY-289
is addressed by your documented approach but I don't know what the
solution would for upgrade would be  if compatibility was removed
entirely.  Can I ask you please to be merciful and hold off  on this
proposal until sometime in 10.3 while we recover from what has already
been proposed in terms of behaviour changes?    If what you have
already  proposed goes  through it is  going to be painful enough for
this round in my humble opinion.

Kathey