How curriculum versioning works
You've proposed, governed, approved and finally offered a brand new third level program to new students. From a curriculum management perspective, you've done your job, right? Time to let the good times enroll!
Well, before you perch your feet on the mantle-piece, it's worth considering whether you’re prepared for future developments in version relationships.
Versioning & Up-versioning
How complicated can a program become, I hear you ask? Well it's no different to any other walk of life. Take car manufacturers. Even after a successful new car release, they must continue releasing further models to keep up with changing market trends and customer demands. While new customers buy the latest model, the manufacturer continues to support existing customers on older models.
Let's call this creation and management of multiple models (or academic programs) "versioning" and the act of revising an existing version to make a change can be known as “up-versioning”. Versioning is an important concept for curriculum management. It facilitates a clear distinction between the version of a program which students are enrolled in this year, and the version we are marketing to prospective students for next year.
Maybe now you've dipped your toes in, you'll go one step further and design a future version of the program, just like a future-state concept car! There’s no harm in getting this ball rolling, just be cognizant that changes may need to apply to both current and all future revisions. The ability to manage multiple program versions allows you to adapt to changing environments, preserve an in-flight offering, and have an auditable track record of contents and changes.
Okay great. We now have students enrolled in the existing program, others showing interest in a new version for next year, and in the background you’ve even proposed modifications to the version starting a couple of years from now. You must feel accomplished.
Figure 1 Up-versioning to future years
But what if all this focus on the future distracted you from an incorrect pre-requisite in this year’s program? Don’t panic! With CourseLoop’s Platform you can easily make urgent updates to the in-flight program for this year, even if it's approved and has future proposed revisions. We call it a revision in the same implementation year. Just as cars are sometimes recalled mid-year for spontaneously combusting, your in-flight program can be updated to include the correct pre-requisite. It is but the work of a moment, or however long you decide your governance process to be…
Figure 2 Up-versioning to future years with a revision in the same year
We’ve covered the concept of different versions, but what about the relationship between a given version and its component parts? Is that something you need to know about? Yes! It is.
In any hardware or software product, component relationships and dependencies are critical. For example, let’s say you bought that new car you had your eye on. And for convenience we will call it the Model M. Your new car will rely on a particular chassis (let’s say chassis v2.0) and perhaps a particular battery, maybe battery v3.0. Let's call that combination of components the "approved version" of the Model M. In this situation, the Model M itself is the “owning item” and the battery and chassis are “containing items”.
Now imagine, in the months following initial launch, upgrades were made to the chassis. This has resulted in a new v2.1 Chassis replacing the now discontinued v2.0 which has ceased production. What does this mean for the 2021 Model M that was released with the v2.0 chassis? Obviously, the manufacturer won’t begin selling it without a chassis, right? Of course not! Instead, the car seamlessly continues production with the Chassis v2.1, which we will refer to as the “working version” of the Model M. This ability to attribute particular versions of containing items (chassis or course) to a particular owning item (car or program) is known as version relationships. Without it, you might release a car with no chassis at all, or a course with an archived minor. We both know which is more detrimental.
Figure 3 Version Relationships
Ultimately, the car model itself hasn't changed; it’s still the 2021 Model M with the same engine components (one engine and one battery). It's simply that the versions of those components have been upgraded. Most importantly, the car model inherits an automatic relationship to the new chassis v2.1. The same applies to curriculum versions. The right software solution can ensure curriculum managers and students know, with confidence, which majors, minors and courses make up their program.
Awesome. You’ve now managed changes to your in-flight program and even observed parallel updates to its containing courses too. Surely there’s no more to it. Well, that depends!
Is it possible for the situation to arise where multiple people are making changes to the same curriculum item? It’s certainly not unheard of. In our Model M example, imagine that while Team A was building and testing a new brake clip design, Team B expedited an upgrade to the size of the wheels. All of a sudden when poor Team A is ready to release their brake clip version, it no longer fits with the latest car model wheels! This situation can easily happen in curriculum management, whereby you may approve one urgent change, while another was still going through governance. It can result in hours of manual analysis to determine the difference between both teams’ improvements. Frustratingly, it often leads to abandoning Team A’s version and re-applying their work in a new version on top of what Team B just approved!
You can easily avoid this nightmare. Advanced curriculum management software includes the ability to “consolidate” or merge versions, alleviating the stress from this situation by achieving the intended result with just a few clicks.
Figure 4 Merged Versions
How CourseLoop handles versioning
One of the CourseLoop Platform’s core value propositions is a single source of truth underpinned by the Curriculum Data Management module. Following structured data definition, the Curriculum Governance module supports your journey in proposing, reviewing and approving curriculum item version changes. The following features from these two modules will assist your curriculum version management:
- Version relationships: automatically update academic item relationships during the revision process
- Track changes: identify the difference between two versions, or even the same version at two different stages of the approval workflow
- Audit history: view the content and author for all changes to a particular data element in a given version
- Discard a proposed version: ability to delete a proposed version, reverting to the previously approved version that year if one exists
- Consolidate versions: identify and merge changes from two revisions which have occurred in parallel from the same source
- Granular permissions management: control who can make changes during the revision process
- Publishing versions: automatically publish the most recently approved version
- Curriculum structure displayed version: view approved academic item structure, view working version of academic item structure, and show/hide version suffixes for clarity
Want to learn more about CourseLoop's Version Control Capability? Get in touch via firstname.lastname@example.org.