Daniel John Debrunner wrote:
Rick Hillegas wrote:
It appears to me that three solutions have been proposed:
1) Call the release 11.0 rather than 10.3. That is, accept the
incompatibilities.
I don't actually see how changing the version number helps, it's still
incompatible.
2) Add an extra security knob. The default setting would be the old
10.2 behavior.
-0.9 Adding properties is not good for the long run, leads to increased
complexity support cost as the number of permutations of runtime modes
increases.
3) Only restrict upgrade/encrypt/shutdown powers to the DBO if both
authorization and authentication are turned on. This does not
eliminate the incompatibilities but should greatly reduce the number
of affected customers.
My vote is for option (3).
+1 for 3)
of the 3 I also would vote for +1 for 3) in hard upgrade/new databases.
I do wonder if there would be value to only apply the new options to
10.3 databases. Should we maintain exact compatibility in the soft
upgrade case?
Dan.
