Yes, enhanced documentation.

The changed behavior was a result of the bug fix, namely, old behavior was considered a bug.
Of course, one can argue that any bug fix is a "change in behavior" and "introduces incompatibility", even if it fixes a crash.

Maybe the documentation can be linked, and the JIRA component updated to show that what was "fixed" was just documentation? Right now, it references "Data Definition - Alter Table", which - when coupled with the "Fixed" resolution - suggests behavior was changed.

When your bug fix for CHECK CONSTRAINT code changes behavior that triggers schema preparation scripts to fail - as it did for Cloudera Manager - in a maintenance release, when CHECK CONSTRAINTS aren't in use, I will argue that it's most certainly an introduced incompatibility.

Thanks - you may also consider adding a note in the 10.2 incompatibilities documentation.

You're right. Sorry for confusion.

"Component" is now Documentation.
The clarification was added to https://mariadb.com/kb/en/library/alter-table/#drop-column

The bug was that DROP COLUMN X in some cases implicitly meant "add new UNIQUE constraint to the column Y". Now if you want all values in the column Y be unique, you need to add a unique constraint explicitly, it won't automagically appear because of some unrelated operation.

Thank you again.

I understand you are referencing MySQL Bug#17098. I agree with the assertion that the historical behavior is inappropriate and non-compliant with standards. I disagree with the decision to make such a change in a maintenance release. I'd argue that behavioral changes such as this should only be made in maintenance releases when the consequences of the defect are severe (data loss, service availability,etc,), and that standards compliance enhancements be reserved for major/minor releases.