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: Shared Components Guidelines
Date Fri, 21 Oct 2005 13:29:42 GMT
Andrew McIntyre wrote:

>
> On Oct 20, 2005, at 4:13 PM, Daniel John Debrunner wrote:
>
>> Is this ok? A vote that refers to a page that is by definition
>> updateable? This means there will be no records in the archives on  what
>> exactly was voted on. Maybe the wiki page could be extracted into the
>> call to vote e-mail.
>
>
> This is why wikis are nice, but STATUS is really the place to keep a 
> record of important votes and proposal type information for 
> posterity. I think it's OK to have the vote on the proposal, but then 
> the vote and proposal should then be recorded in STATUS, and the web 
> page for the proposal should move from the wiki to a permanent place 
> in the website.
>
Perhaps for the voting part it would be good to have a short ballot
measure summarizing what we are doing, the externalized product impact
and the general strategy. This would be something that would not
monopolize the STATUS file and could be understood by those who are
really only interested in the product impact.    Those with a keen
interest in implementation details can continue to review and change the
Wiki page.  Perhaps something like...


Implement a framework to allow code sharing across the product jars that
will  allow derbyclient.jar, derby.jar and derbytools.jar of the same
major version to be loaded  in a  Java VM without having to use
specialized classloaders.  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.   Code sharing will be implemented by  versioning
and deprecating internal API's.  The implementation will not have any
significant impact on jar file size or otherwise affect product
distribution or usage.


That's just a stab at it, but I think it has most of the parts that are
really controversial, covers the significant risk areas, and makes it
clear that users can no longer mix jars across major versions.   I think
it is good to be clear about that since as I see it, that is currently
the only proposed change to external behaviour.  The Wiki page says that
developers should try to avoid breaking compatiblity across major
versions and that's fine,  but  makes no committment, so it is best if 
we just document  that it won't work. 


Kathey



Mime
View raw message