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: Wed, 21 Jun 2006 14:16:48 -0700
From: David Van Couvering <David.Vancouvering@Sun.COM>
Subject: Re: [PRE-VOTE DISCUSSION] Compatibility rules and interface table
In-reply-to: <4499A8A3.9040603@sun.com>
Sender: David.Vancouvering@Sun.COM
To: derby-dev@db.apache.org
Message-id: <4499B740.90309@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>
User-Agent: Thunderbird 1.5.0.2 (X11/20060427)


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?

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


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


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