Description
Currently, we assume that all archival websites are compatible with all versions of archival. Inevitably in the future archival will introduce breaking changes, and sites will exist which are incompatible.
For the most part this is ok - each site bundles the binary for the version of archival it was created with, so these sites will continue to build. However, the archival editor is always built with the latest version of archival, so these sites will no longer be editable with new versions of the editor.
When a developer needs to update their site, they will get an error in archival editor. They should then run ./bin/update-archival.sh, which will auto-update the binaries. However, at this point it is possible that archival will no longer be compatible with their data.
Current solutions
Archival contains an archival compat [version] command for checking for breaking changes, so for sites that don't need the editor, this should help check before updating.
Proposed solution
We should also include an archival migrate command that automatically updates sites (e.g. batch-migrating data types), and then updates the manifest.toml file with a new archival_version, which will then allow editor to resume building it.
Description
Currently, we assume that all archival websites are compatible with all versions of archival. Inevitably in the future archival will introduce breaking changes, and sites will exist which are incompatible.
For the most part this is ok - each site bundles the binary for the version of archival it was created with, so these sites will continue to build. However, the archival editor is always built with the latest version of archival, so these sites will no longer be editable with new versions of the editor.
When a developer needs to update their site, they will get an error in archival editor. They should then run
./bin/update-archival.sh, which will auto-update the binaries. However, at this point it is possible that archival will no longer be compatible with their data.Current solutions
Archival contains an
archival compat [version]command for checking for breaking changes, so for sites that don't need the editor, this should help check before updating.Proposed solution
We should also include an
archival migratecommand that automatically updates sites (e.g. batch-migrating data types), and then updates themanifest.tomlfile with a newarchival_version, which will then allow editor to resume building it.