Need Help? Talk to a specialist: 1-630-543-3747

DicksonOne Software Change Log

Dickson has recently implemented a software change log accessible to all users of DicksonOne. This enables 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 will summarize how to access the change log, the methodology behind the new version numbering system, as well as the individual components of it and what each means to you.
Changelogs access 898

Accessing the Change Log
There are two ways to access the logs: 
  • From your DicksonOne account, click on the "Support" tab. In the dropdown menu, select "Change Logs"* 
  • Alternatively, from any page of DicksonOne, in the footer at the bottom you can click on the version number, as shown here:
Methodology of the Version Number Format
For each software release going forward, Dickson will tag each release with a new version number in what's known as "semantic version number" format. Now to be clear we have always strictly adhered to a version control system. But because the ID number generated by our version control system is really only meaningful internally, we needed to implement a standardized semantic version numbering system to better enable our customers to track components of each release on their own.
"Semantic versioning" is tech-speak for that familiar v1.0.1 you see attached to some software releases. Each of the 3-digits (separated by a period) reference how this particular release impacts the existing application:
  • The "v" prefix, as you might guess, refers to "version"
  • The first 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.
Changelogs view 899

Format of the Change Logs
When viewing the software change logs, each release will follow the same format, as described below:
Each release will have a header that contains:
  • name of the system (DicksonOne)
  • version number (beginning with v1.0.1)
  • Release description
Release Contents
Below each release header will be a table containing each item that is part of the release:
  • The Description column itemizes each component of the release
  • The Impact column categorizes each release item according to its impact on the existing application, according to the following definitions:
  • No impact: No functional change to functions and no impact to data
  • Low impact: Bug fix to return functionality to functional spec or new function with no impact to existing features or data
  • Minor impact: New feature that does not affect existing/core functionality
  • Major impact: New feature affecting existing/core functionality
  • The Recommendation column provides a testing recommendation according the impact level of each item in the release
  • Depending on the impact level in the preceding column, the recommendation will be either:
  • "No testing needed"
  • "Check new functionality" - May require validation or validation review if taking advantage of functional changes.
  • "Testing recommended, including possible regression testing"