db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: Should we vote on it? (was Re: Discussion (in preparation for a vote) on interface stability table)
Date Fri, 31 Mar 2006 00:10:13 GMT
Hi David,

I think you may have already addressed the following issues in email, 
but I don't see the results rolled onto the wiki page. Please pardon my 
nitpicking. This kind of discussion turns me into a tiresome, pedantic 
Mr. Hyde:

1) The cardinal rule. I recommend wordsmithing the cardinal rule: "The 
goal is to allow any application written against the public interfaces 
an older version of Derby can run, without any changes, against a newer 
version of Derby." To me the following formulation reads better "This is 
our goal: An application which ran against Derby yesterday will run 
against a higher version of Derby tomorrow."

But is that really the cardinal rule? Maybe we really mean this: "This 
is our goal: An application which runs against a Derby release today 
will also run tomorrow against the next minor release. We strive to 
minimize churn for applications migrating to the next major release of 
Derby. However these migrations may entail application changes."

2) Bug fixing policy.

I think that the Exceptions section should say explicitly that "It is OK 
for minor releases to fix bugs in our implementation of the standards, 
even if those fixes break existing applications."  Bugfixes can and do 
break applications and so violate the cardinal rule. Here are some more 

2a) Wrong query results. The correct results may break applications 
which are either unaware of the problem or which have already written 
compensatory logic to patch over our error. Correct results may slow 
down the query's performance and the customer may consider this 
degradation intolerable.

2b) Our DRDA implementation may incorrectly transport datatypes not 
recognized by DRDA. Conforming to the DRDA spec may mean removing this 
transport capability and breaking applications which select the 
unsupported datatypes.

3) Client/server compatibility.

I would expect to find these rules spelled out on the wiki page. It is 
not clear to me that you can deduce client/server compatibility from the 
cardinal rule. Are these the rules?

3a) A major release number defines a family of compatible Derby clients 
and servers. Derby clients and servers can interoperate provided that 
they share the same major release number. Say that an application 
currently runs using a client and server from the same family. The 
application will continue to run if the client upgrades to the next 
minor release. The application will also run if the server upgrades to 
the next minor release.

3b) We strive to minimize incompatiblities across release families. 
However, we do not guarantee that a client will interoperate with a 
server having a different major release number. If an application 
upgrades its client to a new major release, the server may have to 
upgrade to the new release family too. Similarly, if an application 
upgrades its server to a new major release, the client may need to 
upgrade too.

4) Interface table.

Here my pedantry goes super-nova: The Comments column for the System 
catalogs notes that adding columns is considered a compabible change. 
Parallel remarks should be added to the Comments columns for SQL 
language, JDBC, Published API, DRDA, Metadata Procedures, SQLStates, 
Tools, and various Properties: For instance, a minor release can 
implement additional SQL features, additional JDBC methods, add new 
methods to the Published API, implement additional DRDA datatypes, add 
new Metadata Procedures, add more SQLStates, add more Tools, add more 
commands and arguments to Tools, and add more Properties..

5) Copy editting.

In the Interface Table, "Jar file manifest entires" should read "Jar 
file manifest entries".


David W. Van Couvering wrote:

> It's been awfully quiet out there.  Are there really no other opinions 
> about this.  One little peep from Dan and another from Kathey, and 
> we're done?  Is this the derby-dev alias I know and love?
> I mean, maybe it's just *that* good that there is no debate, but 
> somehow, I wonder...
> I'll give it another 24 hours, and if there are no other comments, I'm 
> going to basically take the contents of these page and put them up for 
> a vote.  If the vote passes, I'll migrate the contents of the vote to 
> the "main" web site so that our "contracts" around these interfaces 
> stabilities are more or less set in stone, as it were.
> David
> David W. Van Couvering wrote:
>> Hi, all.  I would like to propose that we have a discussion, in 
>> preparation for (at some time in the future) a vote on the interface 
>> table I put together at
>> http://wiki.apache.org/db-derby/ForwardCompatibility
>> The approach I was thinking of is:
>> - everybody who is interested take a look at this table, and raise 
>> issues as needed
>> - discussion ensues as needed
>> - I will incrementally update the Wiki page when it seems there is a 
>> consensus on a particular issue
>> Once things have somewhat stabilized (and where there is contention, 
>> people are starting to repeat themselves :)), I'll then I'll hold a 
>> vote.  The vote email will contain the relevant text and the 
>> interface table from the Wiki page, so that we know what we're voting 
>> on and so that it ends up in the archives.
>> This interface table would be for the next release of Derby (10.1.3 
>> or 10.2, whichever comes first).
>> I would like to suggest that if you want to discuss the stability 
>> classification of a *particular* interface, you do so with a 
>> separate, specific email subject line, so that those who may be 
>> interested will notice and participate.
>> How does this sound?
>> Does anyone think we need to vote on the interface taxonomy and the 
>> definition of an interface separate from the stability 
>> classifications given to each interface?
>> David

View raw message