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 Thu, 30 Mar 2006 22:11:34 GMT
Great comments, thanks

Andrew McIntyre wrote:
 > On 3/30/06, David W. Van Couvering <David.Vancouvering@sun.com> 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?
 > :-) sorry, I've been distracted by other things.
 > Do you have a definition for "incompatible change"? Can you describe
 > what threshold a change has to cross to be an "incompatible change",
 > and how that is measured? Is it a result of tests, running tools, or
 > what? I'd like to see a more firm definition of that term.

Yes, I agree that is missing.  I think what an incompatible change means 
depends upon the type of interface.  I'll try and write something up. 
That in itself will I am sure engender a lot of discussion.  I'll see if 
definitions already exist for some types of interfaces, rather than 
making it all up from scratch.

 > Just on first glance the table is fairly restrictive, but generally
 > looks good. I would think that environment variables and install
 > directory hierarchy would be marked unstable, since it seems
 > reasonable that we could change our use of environment variables
 > (since they're only used in the scripts) or move things around in the
 > distributions between minor releases.

Isn't it possible that scripts written by our users would also make use 
of (e.g. set) environment variables and depend on the install directory 
hierarchy?  That said, as long as we're clear as to how stable these 
interfaces are, our users can be made aware of that and take the 
necessary precautions (like define directory paths in a variable rather 
than hardcode them).

 > In general, I like it. It looks like it should lead to more sensible
 > deprecation of unused or changing features. I'm curious if others feel
 > that only removing deprecated features at major release boundaries is
 > a requirement, or if "keep for x number of releases" might be
 > acceptable.

I think this makes sense, especially if we end up not doing a major 
release for 10 years like Solaris...


 > andrew

View raw message