Product Manuals

This article applies to these plans:

Basic

Standard

Compliant

Enterprise

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
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 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 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 provided information on how impactful the changes are to the software 
  4. Recommendation determine if further testing is needed 
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
 
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

Still need help?

Call 630.543.3747 today or