Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Thu, 22 Jun 2006 05:40:26 -0700
From: Rick Hillegas <Richard.Hillegas@Sun.COM>
Subject: Re: [PRE-VOTE DISCUSSION] Compatibility rules and interface table
In-reply-to: <4499B740.90309@sun.com>
Sender: Richard.Hillegas@Sun.COM
To: derby-dev@db.apache.org
Message-id: <449A8FBA.2030905@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <448F2817.3050006@sun.com> <4499A8A3.9040603@sun.com>
 <4499B740.90309@sun.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)

David Van Couvering wrote:

>
>
> Rick Hillegas wrote:
>
>> Hi David,
>>
>> I had a couple more comments on the compatibility commitments. 
>> Cheers-Rick
>>
>>  - Changes to stored procedures: We will have to change column order if
>>   we add Derby-specific columns to a metadata ResultSet and then a later
>>   JDBC also adds more columns.
>
>
> See Lance's email; OK to leave as is?

I thought the gist of Lance's response was this: It's ok to add 
vendor-specific columns to metadata ResultSets. However, the leading 
columns of the ResultSet must be the columns described in the JDBC spec 
and those columns must appear in the specified order. After that the 
order of vendor-specific columns doesn't matter. However, the names of 
those vendor-specific columns do matter; those names are the stable 
interface. I don't think the existing text on the compatibility webpage 
captures this.

>
>>
>>  - Changes to Database Tables: We should be allowed to drop indexes
>>   on System tables.
>
>
> OK
>
>>
>>  - Changes to Command Line Interfaces. I don't understand why error
>>    message text can't be changed. This contradicts what is said
>>    in the Interface Table below.
>
>
> Hm, good point.  I suppose changing the error message text *is* an 
> incompatible change, but given that the interface is private, it's OK 
> to do it.  But it is a confusing message.  Any suggestions?  I can
>
> (a) remove error message text from the list of incompatible changes
> (b) keep it, but clarify that this is a private interface
> (c) make error message text a public interface
>
> My vote is for (a).  Anyone disagree?

That's my vote too, thanks.

>
>
>>
>>  - Other miscellaneous formats. I'm not clear on what these miscellaneou
>>   files and strings are. For example, I'd like to make sure that 
>> we're not enshrining
>>   the current RUNTIMESTATISTICS output.
>
>
> Again, I think this goes back to the same point.  It's not clear what 
> the relationship is to the classification of an interface in the 
> interfaces table and what it means to make an incompatible change.
>
> I think you're assuming incompatible changes can only apply to public 
> interfaces, because it's really kind of moot/inapplicable for private 
> interfaces.
>
> I think there's value in describing what it means to make an 
> incompatible interface change, but I think the ultimate "truth" in 
> terms of what we actually support in terms of interface stability 
> across releases is described in the interfaces table.   I think some 
> text in the "incompatible changes" section clarifying this would be 
> helpful.
>
> Any thoughts?

I can see that Private Stable applies to the client/server api. These 
apis should remain forward/backward compatible within a release family. 
Do Private Stable interfaces turn up in other situations?

>
>
>>
>>  - Interface table:
>>
>>    o Shouldn't the public client api be stable like the embedded api?
>
>
> Yes
>
>>
>>    o What is meant by "Defaults returned by DatabaseMetadata
>>    methods"?
>>
>
> I don't know, I think I put this in as feedback from someone else.  
> Can anyone clarify?
>
>>    o I think that the format of RUNTIMESTATISTICS output is unstable.
>>
>
> OK, anyone disagree?
>
> Thanks for your review, Rick!
>
> David
>
>>
>> David Van Couvering wrote:
>>
>>> Hi, all.  I am thinking of setting up two separate votes based on 
>>> the Wiki page at
>>>
>>> http://wiki.apache.org/db-derby/ForwardCompatibility
>>>
>>> The first one would be on our overall model/approach to making 
>>> compatibility commitments, as described in the Wiki page.
>>>
>>> The second would be specifically for the interface table, targetted 
>>> at the 10.2 release.
>>>
>>> The reason for separating these out is because, for each release, we 
>>> should update the interface table and have a new vote; the overall 
>>> model/approach does not need to be updated or voted on for each 
>>> release.
>>>
>>> I would copy the appropriate text directly into the email for the 
>>> vote, so that the thing we're voting on is a frozen snapshot, not a 
>>> live document like the Wiki page.
>>>
>>> I'd like your feedback on this approach.  I'd also like to make sure 
>>> there aren't any lingering issues with the Wiki page as it stands, 
>>> before I go through the process of running a vote.
>>>
>>> Thanks,
>>>
>>> David
>>
>>
>>