With so many malware attacks happening in the healthcare sector each year, we should all take updates and upgrades more seriously. Fear mongering aside, there are actually some great benefits to updating your learning environment. Often, bugs that you didn't even realize were affecting you will be fixed and new features will be added.
Here are the top reasons why you should always be updating your learning environment to the latest version.
- Cyber Attacks. It seems like every week, we hear another major news story about a ransomware or malware attack that's affected a huge organization. The older your release, the longer hackers have to find bugs and issues to exploit. Cyber attackers can also read Moodle's release notes, which list the security issues addressed by their latest release. If you neglect to update your system and install the latest security patches, you are increasing your risk of a cyber attacker exploiting the known vulnerabilities of your system.
- Bug Fixes & New Features. While security is a major reason to update software and can't be overstated, there are some cool benefits to software updates. Often you'll see improved performance, bug fixes and/or new features. Since our clients' feedback is at the center of Dual Code's development process, you'll most likely find user experience and user interaction improvements with most new software releases.
- Software End-of-life. As new major releases become available, older releases reach an end-of-life, at which point, Dual Code stops supporting them. Once a release has reached its end-of-life, Dual Code no longer fixes bugs or security issues with that older release. By remaining on this older version, you are not only at risk of a cyber attack, but Dual Code may also not be able to support you.
Upgrade / Update Process
New in 3.9.12. Improvements in both our processes and products means that Dual Code can now offer its clients zero-touch updates. Zero-touch updates mean that clients no longer need to schedule the update of their systems via our Help Desk nor verify the update on their staging server before approving the upgrade of their live environment.
Our release process now requires the successful execution of over 21,000 automated tests against all areas of the system before an update becomes generally available. And that's not all! We then further verify each and every client installation by applying the update to a copy of their live environment and then running a complete system health check. Any reported failure will be inspected by one of our application specialists. If no failures are reported, the system will automatically schedule the update of both your live and staging server and notify all System Administrators.
The system will automatically schedule the production and staging server to be updated at the same time since you are no longer required to review and/or approve the updates. This will eliminate pain points for organizations as well as delays, and in turn reduce your exposure to cyber attacks. Organizations who prefer to assign resources to manually verify the update on their staging server prior to updating their live environment can continue to do so by leveraging tools built-in the learning environment to re-schedule the date and time of their update.
Depending on the nature of the update, administrators also have the option to skip an update. Skipping an update is only possible if the update doesn't contain any high priority security fixes and if the system is no more than 2 versions behind.
Release Schedule
Dual Code's release schedule and versioning scheme is similar to Moodle's schedule for LTS (Long-Term Support) releases. We try to release a new major version every 24 months and a minor release every other month. We also continue to support the older release by providing security updates an critical bug fixes for a one-year period after the newest release is available. This allows you to plan your major upgrades while being assured that your existing release is secure.
The following table highlights some key dates for specific releases of the Dual Code Healthcare Edition in reverse chronological order.
| Version | Availability | Security Updates Only | End of Life |
|---|---|---|---|
| HCE 3.9 | January 25, 2021 | May 16, 2022 | May 15, 2023 |
| HCE 3.5 | September 3, 2018 | September 20, 2021 | December 31, 2021 |
| HCE 3.1 | October 16, 2017 | - | May 13, 2019 |
| HCE 3.0 | March 21, 2014 | - | December 25, 2018 |
| HCE 2.5 | May 14, 2013 | - | December 21, 2015 |
Major and Minor Versions
Starting with version 3.0, the version numbers will consist of three numbers separated by a dot, for example 3.0.3 or 3.1.4. The first two numbers, like 3.0 or 3.1, represent the major version. The third number distinguishes minor versions within the same major version.
Between two minor versions, Dual Code continues to do custom development work and enhancements to Moodle for our customers. These customizations are initially only released to the customer(s) that requested them. If we feel they are valuable for the majority of our customers, Dual Code will include these customizations in our next minor or major release. We may also send these enhancements to Moodle itself if we feel it would be valuable for the Moodle community in general.
Upgrade Expectations
Minor Version: Minor version upgrade process for customers using Dual Code Healthcare Edition typically contain 3-8 new features or feature enhancements, as well as bug fixes and security patches.
- Major Version: During a major version upgrade there may be some major user interface changes that are part of the Moodle, Dual Code HCE, or a third party portion of the software.
Source Code Maturity Level
The Dual Code learning environment, which is based on Moodle, follows the same version numbers as Moodle. In other words, version 3.9.3 of the HCE (Healthcare Edition) contains the same source code as version 3.9.3 of Moodle, with the exception of the enhancements made by Dual Code.
It is not uncommon for new major software releases (not just from Moodle but from any software company) to contain a higher than usual number of software bugs. As such, Dual Code never accepts the first minor version of a major release from Moodle (e.g. 3.0.0, 3.1.0, etc.). Instead, Dual Code waits for until the second, minor release before integrating to it. This ensures a greater maturity level of our source code.
* Moodle is a registered trademark owned by Martin Dougiamas, Founder and Lead Developer of Moodle,