CDB2.2 provides the following new functionality to enhance the accuracy, usability and configurability of the tool.
CDB allows external customers to define their own API classification method. The "Classifier" plug-in is used to specify an access level and a status level for each API entity. External customers can implement their own plug-in to classify the API and still use CDB to extract, compare and generate a report.
The access level assigned to an API entity indicates the scope of the API item. If the scope is reduced, an entity will no longer be visible to the API user in the original access level. This causes a backward compatibility break. For example, if an entity classification is tightened from PublishedPartner to InternalComponent, users of the API in PublishedPartner category will no longer be able to see the entity.
If the source contains inline functions, CDB checks the contents of these functions for backward compatibility breaks.
A database is created to store details of inline functions such as function ID, function name and the description. CDB compares the corresponding entries of inline functions from two databases. Any change in the prototype or the definition of the function is reported as a break.
In CDB2.1, while comparing two versions of a resource file, each difference was reported as a break. Often there will be only one break (for example, a new resource added at the beginning) and the remaining were caused as a result of change in the position. These changes are now shown as ripple breaks by CDB2.2. The actual break is called real break.
CDB2.2 reports any change in the class sizes as a break. The changes are classified into two types:
class size changed due to change in member data
class size changed due to change in Vtable items .
CDB2.2 reports any changes in the orphan header files as a break.