Andrew McIntyre (JIRA) wrote:
One minor comment after rereading the patch, i'm pretty sure that the message SIF03.C was only used in the one location where you've replaced it with SIF03.D, so it might make sense to just reuse the old SIF03.C message id.
Thanks Andrew, 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. 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 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? -bash-2.05b$ svn diff Index: java/tools/org/apache/derby/loc/sysinfoMessages.properties =================================================================== --- java/tools/org/apache/derby/loc/sysinfoMessages.properties (revision 394227) +++ java/tools/org/apache/derby/loc/sysinfoMessages.properties (working copy) @@ -38,7 +38,7 @@ # ZipInfo messages are SIF03.* -SIF03.C=Java Security Exception. +SIF03.C=Java Security Exception: {0} # ZipInfoProperties messages are SIF04.* SIF04.C=<null> thanks, bryan
