💥 Remove unused pulse metadata

[burgholzer]

🤖 AI text below 🤖

Description

Remove QDMI_DEVICE_PROPERTY_PULSESUPPORT and QDMI_Device_Pulse_Support_Level, which have no corresponding pulse-programming interface. Keep provider-specific pulse programs possible without prescribing their design; requirements are tracked in #523.

This is the second metadata-cleanup layer: v1.4 → #512 → #513. No dependency on payload capabilities, multi-program jobs, or replaceable drivers remains. The regular property-enum gap is closed; consumers must rebuild against matching 1.4 headers.

Validation

• Release build: passed, including example and template targets.
• CTest: 81 passed; 18 expected read-only job tests skipped; no failures.
• uvx prek run -a: passed.
• Commit signed and verified. Fresh hosted CI is pending.

AI assistance: Codex separated the stack, preserved current develop tests, and ran local validation.

Pulse submission boundary

Removing the coarse pulse metadata does not remove provider-defined pulse-program submission. Opaque payload transport, compiler-construction metadata, and a standardized pulse programming interface are separate concerns. Keep IQM #200 and #234 linked to #171/#523 without making transport wait for a universal pulse interface.

Before the interface change merges, link a working Core consumer and a demonstration with at least one existing provider, preferably both where applicable. Compatibility evidence suffices when a provider needs no changes. Development revisions may support these tests; published artifacts must use released dependencies. Core adoption: #2233.

Checklist

• The pull request only contains commits that are focused and relevant to this change.
• I have added appropriate tests that cover the new/changed functionality.
• I have updated the documentation to reflect these changes.
• I have added entries to the changelog for any noteworthy additions, changes, fixes, or removals.
• I have added migration instructions to the upgrade guide (if needed).
• The changes follow the project's style guidelines and introduce no new warnings.
• The changes are fully tested and pass the CI checks.
• I have reviewed my own code changes.

If PR contains AI-assisted content:

• I have disclosed the use of AI tools in the PR description as per our AI Usage Guidelines.
• AI-assisted commits include an Assisted-by: [Model Name] via [Tool Name] footer.
• I confirm that I have personally reviewed and understood all AI-generated content, and accept full responsibility for it.

[github-actions]

PR Preview Action v1.8.1
🚀 View preview at https://Munich-Quantum-Software-Stack.github.io/QDMI/pr-preview/pr-513/
Built to branch gh-pages at 2026-09-04 09:34 UTC. Preview will be ready when the GitHub Pages deployment is complete.

[mnfarooqi]

@mortaza-lrz is working on a proposal for QDMI v2. However, if no other breaking changes are introduced in v1.4, keeping the enums intact makes sense. Removing them could create extra overhead for implementers who need to avoid breaking changes caused by shifting enum values.

[burgholzer]

As you can see from this PR stack, QDMI v1.4 will likely contain a few more breaking changes/cleanups.
I'd rather remove aspects that have no credible use in QDMI v1.
If the enum removed here is still relevant for the pulse-level extension in QDMI v2, then it should become part of that module in my opinion.

[mnfarooqi]

As you can see from this PR stack, QDMI v1.4 will likely contain a few more breaking changes/cleanups. I'd rather remove aspects that have no credible use in QDMI v1. If the enum removed here is still relevant for the pulse-level extension in QDMI v2, then it should become part of that module in my opinion.

It's fine for the pulse enums it can be added in v2 when needed. 👍 (The intended emoji appears to be disabled in the repository, or there is a GitHub glitch.)

I was just pointing out the issue of backward compatibility, and how inconvenient it would be for developers trying to develop software stacks that are compatible with all these different versions. Hopefully, from v2 onwards, backward compatibility will be in the list of priorities for QDMI.

[burgholzer]

Hopefully, from v2 onwards, backward compatibility will be in the list of priorities for QDMI.

Definitely. Already now, we are trying to be very mindful with breaking changes and only make them when they genuinely make sense and are driven by a particular use case that was not possible before the change.

I would not expect hosting entities to support multiple major versions of the interface in parallel.
I'd even hope that we can limit the amount of glue code necessary to support multiple minor versions. QDMI v1.x still has the contract that minor versions may introduce breaking changes. Maybe QDMI v2.x is the release where we can bump that to only major releases introducing truly breaking changes. We will have to see. The ecosystem is still developing and changing quickly. Which also means that the requirements for QDMI as an interface are changing quickly for the moment.

[mnfarooqi]

Unfortunately, hosting entities cannot choose which version they support. It depends on the devices being hosted and the QDMI device version supported by their vendors. Some vendors would quickly adopt the newer version, while others would still only support the older version. For now, the only workaround is for hosting entities to have their own layer of abstraction to support multiple versions.

[burgholzer]

Yeah. At MQSC, we are trying very hard to push and support vendors in a quick update/upgrade path, which would hopefully ease the situation in the future.