Course Versioning and Overwriting

Overwriting

Course overwriting allows users to directly overwrite internal course files on the filesystem. This power can be dangerous, as changing the course files themselves might mean that existing registrations are suddenly incompatible with the course.

For this reason, we recommend that only advanced users use the course overwriting feature. However, it is useful for simple typo fixes that do not affect the course structure or otherwise cause issues with existing registrations.

Overwrites can be done through the SCORM Cloud UI. As mentioned in that article, overwriting via the UI can be useful for testing as well, since it prompts the user to reset all existing registrations if the manifest has changed.

Versioning

The notion behind course versioning is that a user uploads a new version of a course. The old version(s) of that course, along with all of the historical data that goes with them, are still kept. New registrations that are created against that course will then use the latest version. This is useful for structural changes that impact existing registrations.

In the API, to create a new version of a course, simply call one of the course import methods with an existing course ID, and the parameter mayCreateNewVersion set to true. To get a list of course versions through the API, call GetCourseVersions.

Existing Registrations

Note: The configuration setting WhenToRestartRegistration described in this section can only be set at the course level. This means that all existing registrations for a course will follow the same rule for moving to the latest version of the course.

As above, new registrations against a course will use the latest course version. The behavior for existing registrations, however, is configurable.

Here are the available choices for the course configuration setting WhenToRestartRegistration. Each of these is checked when the learner launches a registration.

Value
`NEVER` Do not move existing registrations to a newer version (the default)
`WHEN_EXISTING_REG_IS_INCOMPLETE_AND_NEWER_PACKAGE_VERSION_EXISTS` If a registration is marked incomplete (or unknown), move the registration to the latest version
`WHEN_EXISTING_REG_IS_COMPLETE_AND_NEWER_PACKAGE_VERSION_EXISTS` If a registration is marked complete, move the registration to the latest version
`WHEN_EXISTING_REG_IS_FAILED_AND_NEWER_PACKAGE_VERSION_EXISTS` If a registration is marked complete and failed, move the registration to the latest version
`WHEN_EXISTING_REG_IS_SATISFIED_AND_NEWER_PACKAGE_VERSION_EXISTS` If a registration is marked complete and passed, move the registration to the latest version
`WHEN_NEWER_PACKAGE_VERSION_EXISTS` Always move existing registrations to the latest version

Caution

When a registration moves to a later version, a new instance of that registration will be created (that is tied to the newest course version). To the learner, this will effectively reset their progress in the course. Versioning works this way because new course versions may change the structure of the course itself -- especially if multi-SCO -- so we cannot guarantee old registration state is compatible with new course versions.

Data about old instances of registrations, which are probably tied to different course versions, can be retrieved using GetRegistrationInstanceProgress. A list of instances can be retrieved using GetRegistrationInstances