On 4/30/06, Bryan Pendleton <[EMAIL PROTECTED]> wrote:

I was worried that adding a parameter to an existing message might
introduce compatibility problems. I didn't have any specific
reason for this worry; it's just a instinctive feeling that this
is the sort of thing that might be a compatibility worry.

I don't think there's any compatibility concern for sysinfo in a mixed
client/server setup. Sysinfo information is not retrievable by the
client and is never called by the client. It is only available as a
diagnostic on the command line and through the
NetworkServerControl.getSysinfo() method. A copy of sysinfo is
packaged into derbynet.jar, and while it might be present elsewhere
through derby.jar, we only guarantee same versions of engine and
network server to work together anyway, so I think we might be ok.

The only concrete thing I could find was on
http://wiki.apache.org/db-derby/ForwardCompatibility
where it says:

 > Error messages: can not change text of existing error messages. Can add new 
error messages.

But also

 > Error message text
 >
 > Private
 >
 > Note that this means canon-based tests can not make claims that a
 > regression has occurred because the output from error messages has changed

I think this needs some clarification. Are error messages changeable
or not? It's not clear from this text.

So, can we carry this discussion just a bit further? Is a change such as the
following going to create a version compatibility problem, if I chase down
every reference to the message in the current code and ensure that all those
references pass the new parameter?

I think you'll find there's only one location where that particular
message (SIF03.C) is used. :-)

I think its ok to replace the message in this instance. But I
understand if you'd rather err on the side of caution. I'll leave it
up to you to make the decision. As for Kathey's other concern, making
the expected exceptions more user-friendly, I'm not sure what
direction to take.

andrew

Reply via email to