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