db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Re: VOTE: Principles of sharing code
Date Thu, 27 Oct 2005 12:01:13 GMT
David W. Van Couvering wrote:

>
> It seems to me we are very very close to having something people are
> happy with.  If I were to change the wording
>
> FROM
>
> "If the major version of the jars loaded in a JVM differ, the user
> will need to separate the two versions by using separate classloaders. "
>
> TO
>
> "If the major version of the jars loaded in a JVM differ, the user may
> need to separate the two versions by using separate classloaders.  If
> an incompatibility exists, it will be clearly documented.  Any
> undocumented incompatibilities will be treated as a bug."
>
> would anyone be unhappy with this?  PLEASE let me know by Friday.  If
> I don't hear any objections I will put it up for (sigh) another vote.
>
I like this wording better than the other and wouldn't veto it, but I am
fully willing to disclose that I couldn't offer it my binding +1 either
because I think, to use Naka's term, it is a trap.  I don't really
believe that there will be no user impact but will hold you to it.

 I woke up this morning and realized I don't know how I would fix a bug
in shared code with mixed jars, because the class in the other jar would
mask my fix.  I'm sure you have something planned for that and you don't
have to explain it to me now, but  when you submit your patch, the very
first thing  I'll do is 1) try to fix an imaginary customer bug and put
the unchanged  jar first  2) try to add a parameter to a message  with
no impact to the old jars regardless of classpath.  Those should both be
doable  with what you have planned  right?

Kathey





Mime
View raw message