How To: Telling whether a given off-cycle driver update was included in the driver pack:

Finalized hotfixes (“hotfix_CRnnnnnn-MMDDYY”)

the MMDDYY is the date the fix was build. Generally, fixes of this form are included if they fall within the date of the driver pack. For example, the September 2017 driver pack would contain fixes with “08xx17” and “09xx17” in them, which were build in the months of August and September. If a fix is built late in the cycle (say, Sept 29) and missed the freeze date of the pack, the build number is generally artificially advanced to the first of the next month (100117 in this case) to indicate it was not included in the September pack.

Current-Release hotfixes (“currentMMDD”)

fixes of this form are created when the problem was already fixed in a previous case and a “current” version of the driver is being sent to the customer to allow them to get the fix without having to either download the current pack OR wait for the next release (if the fix won’t be released until then). These fixes don’t represent any new code change, so these are always included in the next pack and may even be in the currently released pack (at the time of their creation, the MMDD date)

Beta fixes (“betaMMDD”)

fixes of this form are not checked in to the code for release, as they are experimental and may not fix the problem they were created to fix. They are delivered for testing purposes (sometimes even in cases where a support case has not even been filed yet). A finalized hotfix should be requested after any beta driver is determined to work properly. It is not advisable to keep drivers marked ‘beta’ in the long term, even though they may work just fine (especially if the defect they fix was minor). We test them internally as much as possible, either with a lab device or a simulator based on the customers configuration data, though this is a limited approach.