Allow multiple hardware targets in device schema

[bruno-f-cruz]

Summary

Currently, the device schema supports only a single hardware target under the hardwareTargets field. This proposal suggests changing that field to accept a list of hardware targets instead, to better reflect real-world device configurations and deployment use cases.

protocol/schema/device.json

Lines 21 to 24 in 09440f3

	"hardwareTargets": {
	"description": "Specifies the version of the device hardware.",
	"pattern": "^(0|[1-9]\\d*)\\.(0|[1-9]\\d*)$",
	"type": "string"

Motivation

While tracking this value should in principle have no functional implication at runtime, targeting multiple hardware target versions will allow us to:

• Automate CICD builds - Run one build per target
• Automate releases. Following each build, per target, release N binaries corresponding to the supported hardware versions

Detailed Design

• Should be treated as a list of strings, following semver to make sure it matches the information in R_VERSION
• Should result in a change in the device.json schema spec, and ideally validate against semver

Drawbacks

• I believe this would be a breaking change to the schema unles we support a union of types.
• If we validate against semver we won't allow other string formats
• Since we only use semver, it may be hard to indicate parallel builds across different cores. However, the direction we are going with unified releases I would rather just have a different version if the board gets upgraded anyway. For instance, if 1.1 and 1.2 are ATxMega devices, if the device is then retargetted against the rp2040, it should become 2.0. This would at least allow us to leverage the tag to trigger a different build

Alternatives

Delete this field from the schema. Having it as a single literal value doesn't seem useful.

Unresolved Questions

• Should we allow wild-card matching?

Design Meetings

https://github.com/orgs/harp-tech/discussions/171
https://github.com/orgs/harp-tech/discussions/169