Kathey Marsden wrote:
David W. Van Couvering wrote:
This is an example where we find our code throwing the wrong SQL
State, but are we allowed to fix it? Lance says yes. Others
providing support for customers say (I think) no.
This ties into the discussion about the stability classification for
SQL States. If we mark it as Stable, then we can't change this. If
we mark it as Unstable, then we can.
Comments, thoughts?
I think it is ok and good to change an SQLState or any behaviour to
fix a bug if our current behaviour is non-standard.
OK, I can add that as a note to the row for SQL States.
The question becomes what level of notification do we need to users and
what strategy will we give them to mitigate the impact of the change?
In this case, I think this is new functionality, so all very good it
is caught now and dealt with. If it were existing functionality, I
think that user notification would be very important. I think we need
some way of marking changes that might affect existing users. I made
this proposal a while back for Jira that I think would help:
http://www.nabble.com/New-Jira-Checkbox-proposal-t1200029.html#a3166517
Feedback from Andrew indicated that components are preferred to
checkboxes but being able to query Jira for changes that might affect
users I think is important. What do people think of adding components
for "Release Note Needed", "Existing Application Impact" and "Regression" ?
I think notification is great. I don't understand why what you are
suggesting should be "components" they really seem to me to make sense
as checkboxes -- how are these "components" of the system? Andrew, can
you explain?
David
Kathey
