db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: VOTE: Principles of sharing code
Date Mon, 24 Oct 2005 19:51:53 GMT


Daniel John Debrunner wrote:
> David W. Van Couvering wrote:
> 
> 
>>As suggested by many of you, here is a call vote on the overall
>>intention for how we want to share code, without bogging down in the
>>details.  Thanks to Kathey for a very helpful suggested wording.
>>
>>This vote is to support the overall intention to implement a framework
>>to allow code sharing across the Derby product jars that will allow
>>Derby jars of the same major version to be loaded in a Java VM without
>>having to use specialized classloaders.  Forward and backward
>>compatibility between jar files within the same major version will be
>>implemented using versioning, compatibility tests, and an explicit
>>procedure for deprecating internal APIs.
>>
>>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.
> 
> 
> Is this a requirement, 'will need', since the wiki page says "We should
> strive for forward compatibility between major releases, ..." and
> elsewhere in referring to incompatibility between major releases it says
> "(and this is to be avoided)"?
> 

Perhaps I misunderstood, but I thought Kathey felt that if we did not 
*guarantee* compatibility then it would be simpler and more correct to 
say that a user should expect and plan for incompatibility between major 
releases, rather than hope and pray for compatibility.

I would prefer to word it something like "may need" instead of "will 
need" but I was concerned about pushback from Kathey :)

>>This implementation will not have any significant impact on jar file
>>size or otherwise affect product distribution or usage.
>>
>>The detailed guidelines are being documented and refined on the Derby
>>Wiki site at
>>http://wiki.apache.org/db-derby/SharedComponentVersioningGuidelines.
> 
> 
> I'm a little nervous of the use of and reliance on "major version",
> since we don't have any  guidelines as to when we would change major
> version number. One could read this vote as saying I can break the
> compatibility at any time by just bumping the major version. Is shared
> code really the driver for major version changes?
>

> Does specifying major version add any value to your proposal? Maybe you
> could take the approach that at all times we strive for compatibility.
> If someone in the future wants a change that would cause some
> compatibility issues, they could raise it then with a vote.

Hm.  I do know that it's standard practice to say that incompatibilities 
of any sort of interface be cause for a bump in major version.

I personally would have interpreted this as saying that if someone 
attempts to introduce an incompatibility they will have to wait until 
the next major release, just as if someone were to propose changing the 
database file format in an incompatible way or modifying the 'ij' 
interface in some incompatible way.

In other words, the intent was to provide pushback for incompatible 
changes, not motivation for more frequent major releases.

What I could say is something like "at all time we strive for 
compatibility.  If someone in the future wants a change that would cause 
some compatibility issues, they could raise it with a vote.  Such a 
change would require a bump in the major release."

The last sentence is consistent with the the Jakarta Commons versioning 
guidelines at http://jakarta.apache.org/commons/releases/versioning.html 
-- "Major releases signify significant changes to a component. 
Developers *may* perform a major release if there have been substantial 
improvements to the component. Developers *must* perform a major release 
whenever the new release is not at least interface-compatible the 
previous release."

My point being that our guidelines need to allow customers to be assured 
that that they will *never* see interface incompatibilities between 
minor releases, whereas there is a *possibility* that there is an 
incompatibility between major releases.

> 
> Dan.
> 

Mime
View raw message