Guidelines for deprecation/removal PRs in Qiskit 0.46/1.0

[ElePT]

The Qiskit versioning and deprecation policy around major versions indicates that immediately following new major versions (i.e. 1.0), a final minor version (i.e. 0.46.0) will be released. The purpose of this last minor version (0.46.0) is to include deprecation warnings that document the API changes that take place in 1.0. For this reason, the current Qiskit repository main branch is set to the 1.0 version , and we additionally support a stable/0.46 branch.

Supporting more than one stable branch at the same time makes certain processes trickier than before. To remove code in Qiskit 1.0 that hasn't been previously deprecated in 0.45.0, we generally recommend following this 2-step process:

1. Open a deprecation PR against the stable/0.46 branch issuing deprecation warnings
2. Open a removal PR against the main branch removing the corresponding code

This is the most resource-efficient way to do it. However, some contributors might not be as familiar with different branching strategies, so alternatively, we could also support the following 2-step process:

1. Open a deprecation PR against the main branch issuing deprecation warnings . This PR must then be manually backported to stable/0.46 by leaving a comment with @Mergifyio backport stable/0.46 after the PR is merged (can be done by a maintainer).
2. Open a removal PR against the main branch removing the corresponding code

I wanted to document somewhere how things are generally done, and I'm open to proposals in case there is a way to make things easier for external contributors.

[nkanazawa1989]

Open a removal PR against the main branch removing the corresponding code

Who will open the second PR in this case? A maintainer?

[ElePT]

According to this plan, both the deprecation and the removal PR would be the contributor's responsibility. Backporting (if necessary) would be the maintainers' responsibility.

[1ucian0]

We wrote a small blogpost to give some context on it https://www.ibm.com/quantum/blog/transition-to-1