v1.2.0

@missing-elements/h5p-offline-player 1.2.0, with @missing-elements/h5p-verify 1.4.0 and @missing-elements/h5p-embed 1.3.0. The runtime and the libraries stay at 1.0.0, cmi5 and normalize at 1.1.0. The VS Code extension's 0.2.0 is released separately, as h5p-preview-v0.2.0.

Content made for a newer library version plays on the newest older one

This changes a default. h5p.com gets a library's new minor version weeks before the H5P hub serves it, and the library pack follows the hub. So content made on h5p.com in those weeks can name a version no source has, such as Multiple Choice 1.17 where the pack has 1.16. Up to 1.1.2 the player refused such a package. When the newer version belonged to a part inside the content, such as a question in a Question Set, it booted the package instead and stopped with "Cannot read properties of undefined (reading 'on')", naming nothing.

Now, once every source in libraries has been tried for the version named, the content plays at the newest older minor of the same major that a source has, never across a major. A later source that has the version named still wins over an earlier one with an older version. A package that carries the newer version itself plays its own copy, trusted, as before.

Each library played older is listed in downgradedLibraries, on the element and in the ready event's detail, as { library, from, to }, and the console warns. downgrade-libraries="off" refuses such a package instead, naming the version it needs. That now covers a part inside the content too: its newer version is found before the frame boots, where it used to crash it.

Most minor versions only add fields, which the older code ignores. About one in four changes the shape of the content, which H5P marks with an upgrade step, and there a part can be missing or drawn wrong. Played untrusted, the content is still checked against the older version's fields. Content newer than the pack has the details.

@missing-elements/h5p-verify 1.4.0

The check plays such a package as the player does: it passes, with a warning for each library played older, and report.downgraded lists them. --no-downgrade-libraries, or downgradeLibraries: false in the API, fails it instead, and makes the preview refuse it too. Requires player 1.2.0.

@missing-elements/h5p-embed 1.3.0

The page passes &downgrade-libraries=off through to the element, and the report it posts to the embedding page on ready carries downgradedLibraries. Requires player 1.2.0, so a site written again plays such content. The SCORM writer stays strict: it refuses a package that needs a newer library than the pack has, when the zip is written, as before.

Upgrading

The change is in the element and the Service Worker, so update them together:

• On a CDN, change the player's URL to @missing-elements/h5p-offline-player@1.2.0 and copy its dist/h5p-sw.js onto your site again. The runtime's URL stays at 1.0.0.
• With a bundler, update @missing-elements/h5p-offline-player. The bundler emits the new workers.
• With your own Service Worker that mounts the player (mountH5P), build and deploy it again.
• With copied folders, copy dist/ again.
• An embed site: write it again with npx @missing-elements/h5p-embed@latest <folder> --force, and deploy it.
• A SCORM package needs nothing.
• The VS Code extension: update to 0.2.0.
• To keep refusing such packages, set downgrade-libraries="off" on the element, &downgrade-libraries=off in an embed page's address, or --no-downgrade-libraries on the verifier.

Full Changelog: v1.1.2...v1.2.0