Release 11.x Series
- Seth Petry-Johnson
The 11.x series began with the release of the Application Pathways page, which replaces the Learning Plan List page as the organizing hub of a Practitioner’s credentialing journey.
This series also saw the introduction of the “Long Term Support” / “Long Term Stable” branch.
Overview
For release notes, choose a branch:
Historically, we’ve released new versions of LearningBuilder (e.g. 10.1.x, 10.2.x) every six to eight weeks.
This made things difficult for our Implementation Analysts to manage their client’s annual upgrades because each upgrade would be planned for the latest available release. Thus, each upgrade that an analyst performed would potentially get a new version, making it difficult to create reusable upgrade plans.
The long-term support model addresses this by creating two divergent lines of LearningBuilder:
The LTS release (11.0.x for now) will be updated regularly to contain defect fixes, stability improvements, and low-risk enhancements.
The innovation line (11.1.x, 11.2.x, etc) will contain more significant changes, new features, and anything that doesn’t clear the “low risk” bar for the LTS version.
When a client is upgraded, unless they specifically need new functionality in the innovation line, they will be upgraded to the latest LTS version.
At some point in the future, the innovation line will become the “new LTS version” (e.g. 12.0.0) and the process will start over.
Term | Meaning |
|---|---|
Long Term Support (LTS) release | This is the “designated release” for a given period of time. Every client that gets upgraded during that period of time, and is NOT funding any innovation, gets upgraded to the most recent patch version of the LTS release. A LTS release number always has a zero as the middle digit. (e.g. 11.0.0) |
Innovation release | Major new functionality is released as “innovation releases” These releases are usually fully backwards-compatible, but may require client-specific UAT. |
Patch release | A patch release contains defect fixes and low-risk, backwards-compatible enhancements. Typically, deploying a patch release (to the same major version) does not require client-specific UAT. |
Upgrading into the LTS version
Upgrading a client from 10.0 or earlier into the 11.0.x line does require client-specific UAT, just like with any major upgrade.
However, upgrading within the LTS version does not require client-specific UAT. If a client is on 11.0.1, and 11.0.3 comes out and addresses a defect that affects them, it should be considered safe to upgrade without a full UAT period.
Upgrading into the innovation line
Upgrading a client into the innovation line effectively puts them on the bleeding edge until those new features are absorbed into a new LTS line.
A given innovation release only receives defect fixes until the next innovation release is created.
For example, 11.1.0 was released in March 2022.
If a critical defect is found and fixed in April 2022, this might become 11.1.1.
Let’s assume that 11.2.0 is released in May. Once that happens, there will not be an 11.1.2; if a critical defect is found that affects the clients on 11.1.x, they will need to upgrade to 11.2.x to address it.
What sort of changes will go into the LTS release?
Our goal is to minimize risk and maximize stability. We have guidelines, not hard-and-fast rules, about what can go into an LTS release.
Generally speaking, the LTS release will include:
Defect fixes
Cosmetic improvements
Quality-of-life improvements deemed low risk / unlikely to disrupt existing users
Minor new features that have little to no impact on existing functionality
In some cases, when we are uncertain about the level of risk, we may introduce fixes or changes controlled by feature toggles. These toggles will ensure that existing installations are unaffected unless an analyst specifically opts-in. (These toggles may be removed or enabled-by-default once the next major LTS is created)