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

I believe Zarf should add a field build.VersionRequirements which will contain requirements for a package to run certain operations.

This will work for new fields that change deploy, and changes to the package structure #3813

This will not work on versions of Zarf created before this feature is shipped.

Describe the behavior you'd like

• Given A new feature values is released in version 0.65.0. I create a package with the values key.
• When I deploy my package on version 0.64.0
• Then I receive an error that I must use at least version 0.65.0 to deploy my package.

Details

The field will look like so and will be a list on Zarf package build data :

type OperationRequirement struct {
	// the minimum version of the Zarf CLI that can deploy the package
	Version string 
	// Reasons for why the package can't be deployed
	// EX: "values was not introduced until v0.64.0, package structure changed in v0.65.0"
	Reasons string
}

This field will apply to the following commands

• deploy
• remove
• create (when importing a skeleton package with operationalRequirements set)

There will be a hidden flag introduced --bypass-version-requirement, which a user is prompted with in the error message, if they'd like to continue at their own risk.

Describe alternatives you've considered

Requirements specific to operations

There could be a case where a command will break on deploy, but not break on remove or publish. We could add an operations field to operationRequirements and only error on specific operations, however more often than not the command will break for all commands. Generally we should encourage users to upgrade when their packages are incompatible. It's simpler to error everywhere

.build.LastNonBreakingVersion

There is already a field .build.LastNonBreakingVersion, it currently does not do anything, so this should be easy to deprecate and replace with another name.

This is in a similar problem space as #2728, but in this situation we would error instead of warn. However, a new field does not necessarily imply that the package is not deployable, a new field in .build is not very consequential. Likewise a breaking change in how a field behaves, may stop a package from being deployable on previous versions.