Version your packages like software

Because that is what they are.

A course that has been updated four times without a version scheme produces a specific and avoidable confusion: nobody can say which version a given learner completed, and the evidence of what they were assessed against no longer exists. If the content mattered enough to record completion, it mattered enough to know what was completed.

The scheme need not be elaborate. A version in the course title or description, incremented on republish, plus a short change note held outside the package, covers most needs. What matters is that it is visible from the delivery system without opening the archive.

The harder decision is what to do with learners partway through when an update lands. Replacing content underneath somebody is disruptive and occasionally unfair, particularly where an assessment changed. The usual answer is to let a cohort finish on what they started and apply the new version to the next intake, which requires knowing which cohort is on which version.

All of this is ordinary release discipline borrowed from software, applied to a thing that is software and is usually not treated as such because it was made by a training team rather than a development one.

Version discipline also makes a difficult conversation possible. When somebody asks why a course changed, or whether a particular learner saw the corrected material, the answer is either available in seconds or is not available at all. There is no middle position and no way to reconstruct it later, because the package that was replaced no longer exists anywhere unless somebody deliberately kept it. Keeping the superseded builds costs almost nothing and is the only thing that makes the question answerable.