Fail fast when handling incompatible package

[timblaktu]

Is your feature request related to a problem? Please describe.

zarf package deploying a package that was zarf package created with a version of zarf that uses/used a different packaging format, can cause deploy-time errors related to the breaking schema change. These sorts of indirect errors can be some of the hardest to diagnose. This feature request aims to save users/developers time by catching these earlier and providing explicit clear feedback.

Describe the solution you'd like

As early as possible, zarf package deploy pkg.zst will glean the zarf version used to create pkg.zst, compare that to the running zarf version, and if the delta includes known breaking schema change(s), emit an informative ERROR and exit 1 immediately.

This presupposes that zarf release process uses something like semver, which makes it trivial to check for a breaking transition using arithmetic. If this is not the case, perhaps now would be the time to better define its versioning scheme and compatibility guarantees.

Describe alternatives you've considered

Since we found this in CI originally, we considered implementing this check ourselves in the pipeline steps.

Additional context

@lucasrod16 discovered this to be the cause of some errors UDS team was seeing in zarf-package-big-bang CI. Specifically, our deploy pipeline was using 0.26.4 to deploy a package built with v0.27.0. The 0.27.0 release notes clearly highlight the breaking change:

Internal package structure changes will require packages built with v0.27.0 to be deployed with v0.27.0 or higher by @Noxsios in #1469 and by @Racer159 #1696

Previously built packages are still compatible with v0.27.0, only newly created packages will require the higher version

We would love to have seen zarf deploy instead fail fast with something like:

ERROR: `zarf` v0.26.4 cannot `deploy` a package created with `zarf` v0.27.0 due to a breaking change.

...perhaps followed with some guidance and a built-in reminder about zarf's versioning scheme and compatibility guarantees:

Zarf uses a variant of semver and cannot guarantee inter-operability between instances with different major or minor versions.

..or whatever is appropriate for the actual versioning/compatibility contract zarf prescribes.

[Racer159]

Added the ga label to this

Right now we do breakages on minors even though that is not part of semver because we are not yet GA. We could add a warning when a minor version bump is detected though minors are not guaranteed at this time to have breaking changes (see v0.23.x -> v0.24.x).

What may be a better solution for now is to add a "minimumVersion" field to the build information that Zarf can check and fail on if it is less than that version.