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: Should we vote on it? (was Re: Discussion (in preparation for a vote) on interface stability table)
Date Fri, 31 Mar 2006 00:57:09 GMT

Rick Hillegas wrote:
> 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."

This sounds reasonable to me, and is a summary of our stability 
guarantees descrbed below

> 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 
> examples:
> 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.

Ooh.  I can tell you speak from experience.  I would actually argue that 
this is not acceptable.  You can't just break applications without 
warning.  What I have seen in the past is you provide the user to enable 
the old or new behavior through some kind of flag, e.g. 
derby.use.old.broken.behavior or derby.use.new.fixed.behavior

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

I think it would be unacceptable to remove unsupported datatypes, even 
if they are not spec compliant.  Again, you use versioning and 
capabilities negotiation to change in a compatible way.  For example, if 
someone has an itch to support a network client that can only handle the 
types specified in DRDA, and the network client today supports 
non-standard types, then we should provide an option to run in 
"standard-DRDA" mode and disable those types.

If we want to add new, non-standard types, then we should only support 
these types if the client explicitly says it can handle them.

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

I did add a note based on Kathey's comments.  I think you *can* achieve 
this by declaring the right interfaces as Stable or Private Stable, but 
I agree it's good to call it out.

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

I think this is implied in the definition of Stable and Private Stable 
interfaces, and by ensuring that all interfaces that the network client 
depends upon are marked as either Stable or Private Stable.

I can imagine us providing this kind of wording in our documentation, 
but I am not sure if it is required here, I think it's already covered.

I think your wording does add some clarity about when changes may occur, 
and I may add that to the note about this that I copied from Kathey's 
email onto the Wiki page.

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

I think that I would rather remove this comment and have this discussion 
migrated to the "What is An Incompatible Change" section, which I would 
love you to review.

> 5) Copy editting.
> In the Interface Table, "Jar file manifest entires" should read "Jar 
> file manifest entries".


> Thanks,
> -Rick
> 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