Library Component Versions
In the ADF library versioning schema, sequence-based identifiers are used to convey the significance of changes between releases: changes are classified by significance level, and the decision of which sequence to change between releases is based on the significance of the changes from the previous release, whereby the first sequence is changed for the most significant changes, and changes to sequences after the first represent changes of decreasing significance.
The ADF library components follows this version schema:
In this schema, the ADF uses a three-sequence identifier, the first sequence may be incremented only when the code is completely rewritten, while a change to the function or the documentation may only warrant a change to the thrid sequence.
The major number is increased when there are significant jumps in functionality, the minor number is incremented when only minor features or significant fixes have been added, and the revision number is incremented when minor bugs are fixed. A typical component might use the numbers 0.9 (for beta software), 0.9.1, 0.9.2, 0.9.3, 1.0, 1.0.1, 1.0.2, 1.1, 1.1.1, 2.0, 2.0.1, 2.0.2, 2.1, 2.1.1, 2.1.2, 2.2, etc. Developers have at times jumped (for example) from version 5.0 to 5.5 to indicate that significant features have been added, but not enough to warrant incrementing the major version number, though this is improper.
Example of a major revision
Here are a few examples of major revisions of ADF Library Components
Overhaul of internal methods
Culmination of many minor revisions
Eventually, when many minor revisions are made (e.g. scripts_1_22) it makes more sense to "reset" the component (e.g scripts_2_0).
Example of minor revision
Here are a few examples of minor revisions of ADF Library Components
ceData_1_0.cfc has a method called getCEData() with the following attributes:
If you were to add some new functionality to getCEData() so that it took an XML variable for the search criteria and subsequently removed queryType, searchValues and searchFields and ceData_1_0.cfc now had the following attributes:
You would want to give this cfc a new minor version (e.g. csData_1_1.cfc)
Change return type for a method
ceData_1_0.cfc contains a method called getAllCustomElements which currently returns a query object. If you were to modify this function to return a structure or an array of structures you would want to give ceData_1_0.cfc a new minor version (e.g. csData_1_2.cfc)
If you were to add a new method to ceData_1_0.cfc (e.g. getCountForElementField) you would want to give ceData_1_0.cfc a new minor version (e.g. csData_1_3.cfc)
The removal of any method (e.g. obsolete) would require a new minor version - (e.g. csData_1_4.cfc)
Example of Non major/minor revisions
Any revision to existing methods without modifying the attributes or the return variables would not require a major or minor revision. Essentially, a change of this kind would essentially be seen as a bug fix.
It is important however to update the "version" property tag in the component <cfproperty name="version" value="1_0_0"> Note: the name carries the major/minor (e.g. ceData_1_0) whereas the <cfproperty> tag carries the entire version