This article applies to these plans:
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
- As a user log into DicksonOne.com go to Support > and click Change Logs
- As a non user go to DicksonOne.com/change_logs
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.
- Included the Application Name, the Version number, and the Release Date
- A Description is provided for the type of changes and what changed
- Impact will provided information on how impactful the changes are to the software
- Recommendation determine if further testing is needed
These ratings are evaluated on the 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
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
Still need help?
Call 630.543.3747 today or