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