Change Logs

About the DicksonOne Change Logs

• The DicksonOne Change Logs enable our customers, in particular, those who operate in heavily compliant and/or validated environments to track each individual component of every software release
• This article summarizes how to access the change log, the methodology behind the version numbering system, as well as the individual components of it, and what each may mean to you

How to Access and Understand the Change Log

Section 1: Accessing the Change Logs

The Change Logs page is accessible to both users and non-users

1. As a user log into DicksonOne.com go to Support > and click Change Logs
2. As a non-user go to DicksonOne.com/change_logs

You can always filter by application and select DicksonOne as other Change Logs are included such as device firmware updates Note You can always review Firmware Change Logs for the DWE and TWE/TWP Firmware Updates.

Section 2: Understanding Semantic Versioning

The DicksonOne Change Logs use semantic versioning. Semantic Versioning is tech-speak for that familiar v1.0.1 you see attached to various software releases. Each of the 3-digits (separated by a period) reference how this particular release impacts the existing application:

• The "v" prefix refers to "version"
• The 1st digit (in this case, the first "1" in "v1.0.0") corresponds to the major version of the software in question  It's important to note that this digit will rarely change. But when this does increment to the next number, it means that a major new change to the software has occurred that may impact the core system functionality our users depend on day-to-day. This is particularly important for our customers who operate in heavily compliant and/or validated environments. If you are required to validate your software systems, when this 1st digit changes, you'll likely have to revalidate.
• The 2nd digit denotes minor changes to the software functionality When this digit increments to the next number, it means that some major new features have been added to the existing code base, but core functionality hasn't been impacted. Note that when minor enhancements to existing features are added, even though they are not a bug, they may be treated as a "patch", and thus will not cause this number to change. What will cause this number to change will be significant brand-new features (and thus brand-new code) that doesn't affect or change the underlying core functionality (and the existing code base). For our customers who operate in validated environments, when this digit changes they may want to formally validate all new features that have been implemented as described in the change log, but will not have to re-validate the entire system (as core functionality has not changed).
• The 3rd digit denotes minor patches This could be a bug fix for a core feature or a minor enhancement to an existing feature. For our customers who operate in validated environments, when this digit changes it is not necessary to re-validate the system, in whole or in part.

Section 3: Understanding the Release Content

To do that thing, you do this other thing.

1. Included the Application Name, the Version number, and the Release Date
2. A Description is provided for the type of changes and what changed
3. Impact will provide information on how impactful the changes are to the software
4. Recommendation determine if further testing is needed

Impact ratings These ratings are evaluated on how the change impacts a given feature or set of features and how critical they are to the operation of the system.

• No impact: Bug fix to return functionality to functional spec or new function with no impact to existing features or data
• Low impact: Changes have been made to an existing feature
• Minor impact: New feature that does not affect existing/core functionality
• Major impact: New feature affecting existing/core functionality

Testing recommendations These recommendations are based on how the change(s) would impact user experience, procedures, and/or validation.

• No testing needed: nothing has to be done
• Check new functionality: may require validation or validation review if taking advantage of functional changes
• Testing recommended: includes possible regression testing