Updated changelog with QR rename

[raulotaolea]

Added a new July 2026 section under IQP section with QR rename.

[qiskit-bot]

Thanks for contributing to Qiskit documentation!

Before your PR can be merged, it will first need to pass continuous integration tests and be reviewed. Sometimes the review process can be slow, so please be patient. Thanks! 🙌

One or more of the following people are relevant to this code:

• @abbycross

[abbycross]

Please check my rewording here @raulotaolea

[raulotaolea]

@abbycross In this case, this section refers to the Qiskit Runtime execution environment that runs on the quantum computer itself. It does not refer to the service hosted on IBM Cloud. Therefore, Qiskit Runtime should be kept here.

That said, we should avoid using the term "service" in this context to prevent confusion. Although it is technically a service—internally exposed through the Quantum System API (QSA), which both IQP and HPC integrations interact with at a low level—we want to clearly distinguish it from the IBM Cloud offering, now called IBM Quantum Compute Service.

To make that distinction explicit, I suggest referring to it as IBM Qiskit Runtime. This makes it clear that we are talking about IBM's proprietary implementation of the Qiskit Runtime Execution Environment, rather than the IBM Cloud offering, now called IBM Quantum Compute Service.

[abbycross]

We also have a section in the changelog called Qiskit Runtime client - are we distinguishing that with enough clarity in this case?

[abbycross]

Also @jyu00 do you have a take on this?

[jyu00]

I think leaving it as Qiskit Runtime will make things more confusing 🙂.

Internally we often refer to the non-cloud part of the software stack as Qiskit Runtime, but I don't think that's true externally. Our product is listed as Qiskit Runtime Service, and the first thing you initialize in the client SDK is QiskitRuntimeService.

My proposal is to take this opportunity and combine the existing Qiskit Runtime and IQP sections under a single header - IBM Quantum Compute Service. Especially since the division is a bit arbitrary right now (e.g. store is listed under IQP but measure_2 under QRT, even though they're both part of EDC support).

[jyu00]

My suggestion was actually to merge the existing IBM Quantum Platform section with the Qiskit Runtime section and name it IBM Quantum Compute Service. This merged section would then cover all server-side changes (besides Functions), so people don't have to try to understand the different component names. Functions are separated out because it's a separately licensed entity.

[abbycross]

I've taken a stab at combining the two as Jessie suggests, and interleaved the archival entries.

[abbycross]

Since this PR doesn't have a preview, here are screenshots from my local build

[raulotaolea]

I wrote the text in the screenshot assuming we would keep a dedicated section for Qiskit Runtime, understood as the execution environment, and I prefixed it with IBM to make it clear that it refers to IBM's implementation of Qiskit Runtime.

Now that we've decided to simplify the model and present IBM Quantum Compute Service as the main concept, I'm not sure whether that explanation still makes sense. My original intention was simply to explain the different components involved in the execution flow and how they relate to each other.

Do you think it's still worth describing those underlying components in this context, even if we don't expose them elsewhere or have dedicated sections for them? Or would you rather treat IBM Quantum Compute Service as a black box and avoid introducing those implementation details altogether?

If we go with the latter approach, we could write something along these lines:

Qiskit Runtime Service is now IBM Quantum Compute Service — This is a naming change only and does not require any code changes or updates to existing applications. You might notice the new name throughout the user interface and documentation.

IBM Quantum Compute Service is the quantum execution service within IBM Quantum Platform for running workloads on IBM Quantum systems. It provides the cloud capabilities required to execute workloads reliably at scale, including authentication, scheduling, queue management, workload routing, usage tracking, limits, and analytics.

The open-source qiskit-ibm-runtime library continues to be the client used to submit workloads from Qiskit applications. Existing APIs, workflows, access plans, and the user experience remain unchanged.

This renaming clarifies the role of the service without changing how applications are developed or executed.

[raulotaolea]

My suggestion was actually to merge the existing IBM Quantum Platform section with the Qiskit Runtime section and name it IBM Quantum Compute Service. This merged section would then cover all server-side changes (besides Functions), so people don't have to try to understand the different component names. Functions are separated out because it's a separately licensed entity.

I agree with merging the existing Qiskit Runtime section into IBM Quantum Compute Service. That aligns well with the goal of simplifying the terminology presented to users.

However, I don't think the same applies to the IBM Quantum Platform section. Regardless of the rename itself, from a product perspective I think it's important that we continue to distinguish between the platform and the services it provides.

IBM Quantum Platform is the platform. IBM Quantum Compute Service is one of the services within that platform. They represent different layers of the product hierarchy, and I think our changelog should reflect that distinction rather than hide it. Otherwise, platform-level changes -- such as documentation, learning content, Composer, and similar capabilities -- would gradually end up being described as changes to IBM Quantum Compute Service, even though they belong to IBM Quantum Platform.