Skip to content

Commit ab54d22

Browse files
abbycrossEric-Arellano
abbycross
and
Eric-Arellano
authored
Fill in content for additional resources tab (#1718)
Closes #1698 --------- Co-authored-by: Eric Arellano <[email protected]>
1 parent dde8afe commit ab54d22

File tree

3 files changed

+178
-5
lines changed

3 files changed

+178
-5
lines changed

‎docs/open-source/code-of-conduct.mdx

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -65,7 +65,8 @@ Examples of unacceptable behavior by participants, even when presented as
6565
- Other conduct which could reasonably be considered inappropriate in a
6666
professional setting
6767

68-
## Responsibilities & Enforcement
68+
<span id="responsibilities-enforcement"></span>
69+
## Responsibilities and enforcement
6970

7071
The entire Qiskit community is responsible for upholding the terms of the Code
7172
of Conduct in Qiskit Community events and spaces and reporting violations if

‎docs/open-source/qiskit-sdk-version-strategy.mdx

Lines changed: 130 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,135 @@
11
---
22
title: Qiskit SDK version strategy
3-
description: TODO - filler text so that the SEO check doesn't complain!
3+
description: Details on the Qiskit SDK versioning strategy, release schedule, upgrade strategy, pre-releases, post-releases, and how contributors can mark deprecations.
44
---
55

66
# Qiskit SDK version strategy
7+
8+
Qiskit version numbers follow [Semantic Versioning](https://semver.org/).
9+
The version number is comprised of three primary components: the major, minor, and
10+
patch versions. For example, in version number `X.Y.Z`, `X` is the major version,
11+
`Y` is the minor version, and `Z` is the patch version.
12+
13+
Breaking API changes are reserved for major version releases. The **minimum**
14+
period between major version releases is one year. Minor versions introduce
15+
new features and bug fixes without breaking API compatibility, and are
16+
periodically (currently every three months) published for **only** the
17+
current major version. Patch versions provide fixes for bugs identified in
18+
the most recent minor version of each actively supported release series (that is, the
19+
major version). We support at most two release series at a time, which occurs
20+
only during the period of overlap following a new major version release,
21+
described in more detail below.
22+
23+
24+
## Release schedule
25+
26+
27+
A tentative release schedule is included below:
28+
29+
![Tentative Qiskit release schedule](/images/guides/install/release_schedule.png)
30+
31+
For an up-to-date release schedule, refer to the Qiskit Github project's [milestones list](https://github.com/Qiskit/qiskit/milestones), which will always contain the current release plan.
32+
33+
With the release of a new major version, the previous major version is supported
34+
for at least six months; only bug and security fixes are accepted during this time and only patch releases are published for this major version. A final
35+
patch version is published when support is dropped, and that release
36+
also documents the end of support for that major version series. A longer
37+
support window is needed for the previous major version as this gives downstream
38+
Qiskit consumers and their users a chance to migrate their code.
39+
Downstream libraries that
40+
depend on Qiskit should not raise their minimum required Qiskit version to a new
41+
major version immediately after its release because the library's user base needs time
42+
to migrate to the new API changes. Having an extended support window
43+
for the previous major Qiskit version gives downstream projects time to ensure
44+
compatibility with the next major version. Downstream projects can provide
45+
support for two release series at a time to give their users a migration path.
46+
47+
For the purposes of semantic versioning, the Qiskit public API is considered
48+
any documented module, class, function, or method that is not marked as private
49+
(with an underscore `_` prefix). However, there can be explicit exceptions made for
50+
specific documented APIs. In such cases, these APIs will be clearly documented
51+
as not being considered stable interfaces yet, and a user-visible warning will be
52+
actively emitted on any use of these unstable interfaces. Additionally, in some
53+
situations, an interface marked as private is considered part of the public
54+
API. Typically this only occurs in two cases: either an abstract interface
55+
definition where subclasses are intended to override/implement a private method
56+
as part of defining an implementation of the interface, or advanced-usage
57+
low-level methods that have stable interfaces but are not considered safe to use,
58+
as the burden is on the user to uphold the class/safety invariants themselves
59+
(the canonical example of this is the `QuantumCircuit._append` method).
60+
61+
The supported Python versions, minimum supported Rust version (for building
62+
Qiskit from source), and any Python package dependencies (including the minimum
63+
supported versions of dependencies) used by Qiskit are not part of the backwards
64+
compatibility guarantees and may change during any release. Only minor or major
65+
version releases will raise minimum requirements for using or building Qiskit
66+
(including adding new dependencies), but patch fixes might include support for
67+
new versions of Python or other dependencies. Usually the minimum version of a
68+
dependency is only increased when older dependency versions go out of support or
69+
when it is not possible to maintain compatibility with the latest release of the
70+
dependency and the older version.
71+
72+
## Upgrade strategy
73+
74+
When a new major version is released, the recommended upgrade path
75+
is to first upgrade to the most recent minor version on the previous major
76+
version. Shortly before a new major version, a final minor version will
77+
be published. This final minor version release `X.Y+1.0.0` is equivalent to
78+
`X.Y.0` but with warnings and deprecations for any API changes that are
79+
made on the new major version series.
80+
81+
For example, immediately proceeding the 1.0.0 release, a 0.46.0 release will be
82+
published. The 0.46.0 release will be equivalent to the 0.45.0 release but with
83+
additional deprecation warnings that document the API changes that were made as
84+
part of the 1.0.0 release. This pattern will be used for any future major
85+
version releases.
86+
87+
Qiskit users should first upgrade to this final minor
88+
version to see any deprecation warnings and adjust their Qiskit
89+
usage before trying a potentially breaking release. The previous
90+
major version will be supported for at least six months to give sufficient time
91+
to upgrade. A typical pattern to manage this is to pin the maximum version to
92+
avoid using the next major release series until you're sure of compatibility.
93+
For example, specifying `qiskit<2` in a requirements file when the current
94+
major Qiskit version is 1 ensures that you're using a version of Qiskit
95+
that doesn't have breaking API changes.
96+
97+
Capping the version less than the next major version
98+
ensures that you see any deprecation warnings before a
99+
major version release.
100+
Without the cap, `pip` installs
101+
the newest version available by default.
102+
103+
The QPY serialization format is backwards-compatible so that a new Qiskit release can always load a QPY
104+
file generated with an earlier release of Qiskit. However, the format isn't forward-compatible so, in principle, it's not possible
105+
to load QPY files generated with a newer version of Qiskit using an older release. To facilitate user migration across major version releases, the [`qiskit.qpy.dump()`](/api/qiskit/qpy#dump) function will always support at least one overlapping version between the `X.0.0` and the `X-1.Y.0` release (where `Y` is the last minor version of
106+
that series). The parameter `qiskit.qpy.dump(..., version=...)` will enable saving QPY format files that can be loaded by both major versions from the newer
107+
release. See more details in [RFC 0020](https://github.com/Qiskit/RFCs/blob/master/0020-release_cycle.md#qpy-support).
108+
109+
## Pre-releases
110+
111+
For each minor and major version release, Qiskit publishes pre-releases that
112+
are compatible with [PEP440](https://peps.python.org/pep-0440/). Typically
113+
these are release candidates of the form `X.Y.0rc1`. The `rc` releases
114+
will have a finalized API surface and are used to test a prospective release.
115+
116+
Note that when one of the PEP440 pre-release suffixes (such as `a`, `b`, or `pre`) are
117+
published, it does not have the same guarantees as an `rc` release, and is
118+
only a preview release. The API might change between these pre-releases
119+
and the final release with that version number. For example, `1.0.0pre1` might have
120+
a different final API than `1.0.0`.
121+
122+
123+
## Post-releases
124+
125+
If there are issues with a release's packaging, a post-release might be
126+
issued to correct this. These will follow the form `X.Y.Z.1` where the fourth
127+
integer indicates that it is the first post-release of the `X.Y.Z` release.
128+
For example, the qiskit-terra (the legacy package name for Qiskit) 0.25.2
129+
release had some issue with the sdist package publishing, and a post-release
130+
0.25.2.1 was published that corrected this issue. The code was identical, and
131+
0.25.2.1 only fixed the packaging issue for the release.
132+
133+
## How contributors can mark deprecations
134+
135+
Refer to the [deprecation guide](https://github.com/Qiskit/qiskit/blob/main/DEPRECATION.md) in the Qiskit SDK repository for instructions on how to add deprecations to the source code.

‎docs/responsible-quantum-computing.mdx

Lines changed: 46 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,49 @@
11
---
2-
title: Responsible quantum computing
3-
description: TODO - filler text so that the SEO check doesn't complain!
2+
title: Responsible quantum computing and inclusive tech
3+
description: A review of the Responsible Quantum Principles at IBM, and how to report a Responsible Quantum Issue
4+
45
---
56

6-
# Responsible quantum computing
7+
# Responsible quantum computing and inclusive tech
8+
9+
Quantum technology has the potential to accelerate use cases and even solve problems that were previously inaccessible. But how will this new computing power impact society at large? This requires us to be thoughtful — we must research and develop responsibly.
10+
11+
Our mission statement at IBM&reg; is to be “the catalyst to make the world work better,” and IBM Quantum&trade; runs a Responsible Quantum Initiative to ensure that our development is in line with that mission.
12+
13+
We define Responsible Quantum Computing as quantum computing that’s aware of its effects. As part of this effort, we crafted five Responsible Quantum Principles for developing and deploying quantum technology that our team follows internally.
14+
15+
**1. Make a positive societal impact.**
16+
17+
We are developing a new form of technology. We are doing so because IBM is the catalyst to make the world work better. Therefore, quantum computing, too, should make the world work better by prioritizing use cases that make a positive societal impact.
18+
19+
**2. Explore use cases with foresight.**
20+
21+
Developing a new technology means we may unlock use cases or algorithms that never existed before. We must be prepared for unintended impacts to use cases that seem positive.
22+
23+
**3. Promote our products accurately.**
24+
25+
As innovators, it is our responsibility to ensure that the world is aware of quantum’s promise, its limitations, and the expected development timeline.
26+
27+
**4. Make consistent principled decisions.**
28+
29+
It is the responsibility of IBM Quantum employees and IBM Quantum leadership alike to uphold these principles. Where decisions come in conflict with these principles, it is the responsibility of leadership to make decisions consistently.
30+
31+
**5. Build a diverse and inclusive quantum community.**
32+
33+
IBM Quantum is building a global quantum computing ecosystem. It is our responsibility to create an ecosystem that represents the diversity of the world at large, and be inclusive of people of all backgrounds, experiences, and abilities.
34+
35+
We have several tools to ensure that our products are used responsibly as well. We monitor responses to this [Responsible Quantum Issue Report form](https://airtable.com/app1Nb37drhJb4ljK/shrHQJBat48X3WmfA) where you can flag any potential concerns about a quantum computing application or use case. Furthermore, in the [IBM Quantum End User Agreement](https://quantum.ibm.com/terms), please take note of three sections, which describe acceptable and responsible uses of IBM Quantum technology and services.
36+
37+
> **9.b** *IBM Quantum may not be used for unlawful, obscene, offensive or fraudulent activity, such as advocating or causing harm, interfering with or violating the integrity or security of a network or system, evading filters, sending unsolicited, abusive, deceptive or disparaging messages, viruses or harmful code, violating third party rights, for the research, design, development, production, maintenance, repair, overhaul, or use of any offensive or defensive weapons of any kind, for attempting to defeat encryption, or for processing regulated data including personal information, financial data and health data. In addition, IBM may remove or refuse to accept or use any Content without limitation.*
38+
>
39+
> **9.c** *You may not reverse engineer or otherwise attempt to discover or decode any hardware component of IBM Quantum.*
40+
>
41+
> **9.d** *You may not use IBM Quantum in any application or situation where failure could lead to death or serious bodily injury of any person, or to severe physical or environmental damage, such as aircraft, motor vehicles or mass transport, nuclear or chemical facilities, life support or medical equipment, or weaponry systems.*
42+
43+
Finally, as part of our responsible quantum effort, we are committed to fostering a welcoming community of users, both online and at in-person engagements. Please familiarize yourself with the [Qiskit Code of Conduct](/open-source/code-of-conduct) and its [enforcement procedures](/open-source/code-of-conduct#responsibilities-enforcement).
44+
45+
<Admonition type="tip" title="Learn more">
46+
- [IBM Quantum Safe](https://www.ibm.com/quantum/quantum-safe)
47+
- [Blog: The era of quantum utility must also be the era of responsible quantum computing](https://www.ibm.com/quantum/blog/responsible-quantum)
48+
- [IBM Research Responsible and Inclusive Tech](https://research.ibm.com/projects/responsible-and-inclusive-tech-research)
49+
</Admonition>

0 commit comments

Comments
 (0)