_write_parameter_expression takes version parameter

[kt474]

Summary

@jakelishman version was added as a new argument here which I believe caused our unit tests against Qiskit/main to start failing. Is this the correct way to handle version from the provider?

Details and comments

[coveralls]

Pull Request Test Coverage Report for Build 9119300455

Details

• 2 of 3 (66.67%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.009%) to 82.756%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
qiskit_ibm_runtime/utils/json.py	2	3	66.67%

Totals
Change from base Build 9117820651:	-0.009%
Covered Lines:	6239
Relevant Lines:	7539

---

💛 - Coveralls

[jakelishman]

That's probably the calling convention for it now, yeah, but that's very much not a public API function, and we cannot make guarantees that it'll even continue to exist in the future, given that we may well need to refactor the QPY export to be faster.

[jakelishman]

This version wants to be compatible (less than) whatever version of QPY you'll be using on the backend to deserialise - QPY_VERSION will always be the max the local version of Qiskit can handle.

[kt474]

Is the use of QPY_VERSION incorrect here then? I don't believe the server side has updated to qiskit 1.1 yet

[mtreinish]

You should repeat the logic in other places around the version kwarg and keep the version there the same as in other places. It might makes sense to extract that to a constant like RUNTIME_QPY_VERSION = 11 or something.

if (_TERRA_VERSION[0] == 1 and _TERRA_VERSION[1] >= 1) or _TERRA_VERSION[0] > 1:
    kwargs["version"] = 11

[jyu00]

From the Slack discussion I think we can just drop the support for ParameterExpression type, since it's not an input type to primitives anymore.

[kt474]

From the Slack discussion I think we can just drop the support for ParameterExpression type, since it's not an input type to primitives anymore.

Closing this PR, i'll open a separate one