Thanks, David. I think this discussion is raising some interesting issues.
David W. Van Couvering wrote:
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
I am glad that we are bothering to make these rules explicit. In a
previous life at Sybase, we solved this problem by adding special
tracepoints for big, important customers who relied on old, incorrect
behavior. As I recall, we didn't know up front who would object to a
correction. The tracepoints went into patch releases based on customer
dissatisfaction with the last minor release.
Do you think the Sybase model will work for us? Or do we need to add
tracepoints to the minor release as we fix the incorrect behavior? Maybe
it is not good enough to add a master tracepoint with the semantics
"Simulate all incorrect implementations of the standards fixed in this
release, X.y." Customers may want something more granular, say, a
tracepoint per obnoxious correction. Over time, these tracepoints will
pile up and the code will become a more exciting pinball machine. What
are your thoughts?
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.
I'm happy with this approach. I would like to see the wiki state these
rules explicitly.
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.
Thanks.
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.
Thanks.
