|
| 1 | +# Manifests |
| 2 | + |
| 3 | +Manifests are used to track the current public API of the Arm backend. They are |
| 4 | +generated with |
| 5 | +`python backends/arm/scripts/public_api_manifest/generate_public_api_manifest.py`. |
| 6 | + |
| 7 | +## Running manifest |
| 8 | + |
| 9 | +There is always one running manifest which has the main purpose of tracking the |
| 10 | +API surface inbetween releases. |
| 11 | + |
| 12 | +## Static manifests |
| 13 | + |
| 14 | +At any given time there may be up to two static manifests. These are generated |
| 15 | +in conjunction with a release and are used to track the API surface of that |
| 16 | +release. The main purpose of these is to make sure backwards compatibility. |
| 17 | + |
| 18 | +A static manifest may never be changed. It belongs to a release and must be kept |
| 19 | +as is. |
| 20 | + |
| 21 | +A static manifest should not live longer than 2 releases. It may then be |
| 22 | +removed. |
| 23 | + |
| 24 | +# On release |
| 25 | + |
| 26 | +With each release, check that the running manifest is up to date and reflects |
| 27 | +the API surface of the release. Then, copy the running manifest to a new static |
| 28 | +manifest for the release. This can be done by running |
| 29 | +`cp <running_manifest> <static_manifest>`. The new static manifest should be |
| 30 | +named according to the release, e.g. `api_manifest_1_3.toml` for release 1.3 and |
| 31 | +so on. If there are now more than two static manifests, remove the oldest one in |
| 32 | +the same commit. |
| 33 | + |
| 34 | +# API changes |
| 35 | + |
| 36 | +When introducing an API change, the running manifest must be updated to reflect |
| 37 | +the change. This is done by running the manifest generation script, |
| 38 | +`python backends/arm/scripts/public_api_manifest/generate_public_api_manifest.py`. |
| 39 | +This updates the running manifest. |
| 40 | + |
| 41 | +To validate the running manifest directly, run |
| 42 | +`python backends/arm/scripts/public_api_manifest/validate_public_api_manifest.py`. |
| 43 | + |
| 44 | +To validate all manifests, use `backends/arm/scripts/pre-push`. This is the |
| 45 | +check that must pass before the change is ready to merge. |
| 46 | + |
| 47 | +Manifest validation only checks the API surface and signatures. Workflow-level |
| 48 | +backward compatibility is covered separately by the scenario runner described |
| 49 | +below. |
| 50 | + |
| 51 | +Running-manifest validation uses exact signature matching. Any intentional API |
| 52 | +change must update `api_manifest_running.toml`. |
| 53 | + |
| 54 | +Static-manifest validation uses backward-compatibility matching. The old |
| 55 | +release signature must still be callable against the current API. For example, |
| 56 | +adding a trailing optional parameter is accepted for static manifests, while |
| 57 | +removing a parameter, reordering parameters, or adding a new required |
| 58 | +parameter still fails validation. |
| 59 | + |
| 60 | +## Backward-compatibility scenarios |
| 61 | + |
| 62 | +Workflow-level backward compatibility is checked by |
| 63 | +`python backends/arm/test/public_api_bc/run_public_api_bc_scenarios.py`. |
| 64 | + |
| 65 | +The runner hardcodes the current canonical public API workflow scripts: |
| 66 | + |
| 67 | +- `backends/arm/test/public_api_bc/test_ethosu_flow.py` |
| 68 | +- `backends/arm/test/public_api_bc/test_vgf_fp_flow.py` |
| 69 | +- `backends/arm/test/public_api_bc/test_vgf_int_flow.py` |
| 70 | + |
| 71 | +These scripts should be updated continuously to reflect the current public API. |
| 72 | +The runner materializes those same paths into a temporary harness and executes |
| 73 | +them there with pytest so they import the latest installed |
| 74 | +`executorch.backends.arm` package instead of the repository source tree. |
| 75 | + |
| 76 | +The rolling support window is controlled by the `OLDEST_SUPPORTED_REF` constant |
| 77 | +in `backends/arm/test/public_api_bc/run_public_api_bc_scenarios.py`: |
| 78 | + |
| 79 | +- If `OLDEST_SUPPORTED_REF` is empty, the runner uses the current workspace. |
| 80 | + This is the bootstrap mode until a release contains the scenario scripts. |
| 81 | +- Once a release contains the scripts, the release epic should update |
| 82 | + `OLDEST_SUPPORTED_REF` to the oldest still-supported release ref. |
| 83 | +- At that point the runner uses `git show <ref>:<path>` to fetch the old |
| 84 | + release's scripts and run them against the latest code. |
| 85 | + |
| 86 | +When an old release falls out of the support window, update |
| 87 | +`OLDEST_SUPPORTED_REF` to the next newer supported release. That is how the |
| 88 | +backward-compatibility window rolls forward. |
| 89 | +Reasons for passing validation may include: |
| 90 | +- Adding a new API symbol and adding it to the running manifest. |
| 91 | +- Removing an API that was marked as deprecated and no longer exists in any |
| 92 | + manifest. |
| 93 | +- Deprecated symbols do not break backward compatibility with static |
| 94 | + manifests. |
| 95 | +- Deprecating a symbol removes it from the running manifest, but it can only be |
| 96 | + removed fully once it no longer appears in any static manifest. |
| 97 | +- Extending a static-manifest signature in a backward-compatible way, such as |
| 98 | + adding a trailing optional parameter. |
| 99 | + |
| 100 | +Reasons for failing validation may include: |
| 101 | +- Removing an API symbol without deprecation. |
| 102 | +- Changing a running-manifest signature without regenerating the running |
| 103 | + manifest. |
| 104 | +- Changing a static-manifest signature in a non-backward-compatible way. |
| 105 | +- New API symbol added but not added to the running manifest. |
0 commit comments