주 콘텐츠로 건너뛰기

Qiskit SDK 버전 전략

Qiskit 버전 번호는 Semantic Versioning을 따릅니다. 버전 번호는 주요(major), 부(minor), 패치(patch) 버전의 세 가지 기본 구성 요소로 이루어집니다. 예를 들어, 버전 번호 X.Y.Z에서 X는 주요 버전, Y는 부 버전, Z는 패치 버전입니다.

API 변경 사항의 하위 호환성 파괴는 주요 버전 출시에만 적용됩니다. 주요 버전 출시 사이의 최소 기간은 1년입니다. 부 버전은 API 호환성을 파괴하지 않고 새로운 기능과 버그 수정을 도입하며, 현재 주요 버전에 대해서만 주기적으로(현재 3개월마다) 게시됩니다. 패치 버전은 각 활성 지원 릴리스 시리즈(즉, 주요 버전)의 가장 최근 부 버전에서 발견된 버그에 대한 수정을 제공합니다. 동시에 최대 두 개의 릴리스 시리즈를 지원하며, 이는 새로운 주요 버전 출시 이후 중복 기간 동안에만 발생하며, 자세한 내용은 아래에 설명되어 있습니다.

출시 일정

아래에 잠정적인 출시 일정이 포함되어 있습니다:

잠정적인 Qiskit 출시 일정

최신 출시 일정은 Qiskit GitHub 프로젝트의 마일스톤 목록을 참조하세요. 이 목록에는 항상 현재 출시 계획이 포함되어 있습니다.

새로운 주요 버전이 출시되면, 이전 주요 버전은 버그 수정만으로 최소 6개월 동안 지원되며, 보안 수정으로는 1년 동안 지원됩니다. 이 기간 동안 해당 주요 버전에 대해서는 패치 출시만 게시됩니다. 지원이 종료될 때 최종 패치 버전이 게시되며, 해당 릴리스에는 해당 주요 버전 시리즈의 지원 종료가 문서화됩니다. 이전 주요 버전에 대해 더 긴 지원 기간이 필요한 이유는, 이것이 다운스트림 Qiskit 소비자와 그 사용자들에게 코드를 마이그레이션할 기회를 제공하기 때문입니다. Qiskit에 의존하는 다운스트림 라이브러리는 새로운 주요 버전이 출시된 직후에 최소 요구 Qiskit 버전을 새 주요 버전으로 올려서는 안 됩니다. 이는 라이브러리의 사용자 기반이 새로운 API 변경 사항으로 마이그레이션할 시간이 필요하기 때문입니다. 이전 주요 Qiskit 버전에 대한 확장된 지원 기간은 다운스트림 프로젝트가 다음 주요 버전과의 호환성을 보장할 시간을 제공합니다. 다운스트림 프로젝트는 사용자에게 마이그레이션 경로를 제공하기 위해 동시에 두 개의 릴리스 시리즈를 지원할 수 있습니다.

시맨틱 버전 관리의 목적에 따라, Qiskit 공개 API는 개인(private) 표시가 없는 (언더스코어 _ 접두사 없음) 문서화된 모든 모듈, 클래스, 함수 또는 메서드로 간주됩니다. 그러나 특정 문서화된 API에 대해 명시적인 예외가 있을 수 있습니다. 이러한 경우, 해당 API는 아직 안정적인 인터페이스로 간주되지 않는다고 명확히 문서화되며, 이러한 불안정한 인터페이스를 사용할 때마다 사용자에게 표시되는 경고가 적극적으로 발생합니다. 또한, 일부 상황에서는 비공개로 표시된 인터페이스가 공개 API의 일부로 간주됩니다. 일반적으로 이는 두 가지 경우에만 발생합니다: 서브클래스가 인터페이스 구현을 정의하는 일환으로 비공개 메서드를 재정의/구현하도록 의도된 추상 인터페이스 정의이거나, 안정적인 인터페이스를 가지고 있지만 사용하기에 안전하지 않다고 간주되는 고급 사용 저수준 메서드(사용자가 직접 클래스/안전 불변성을 유지해야 하는 부담이 있음)입니다 (이것의 표준적인 예는 QuantumCircuit._append 메서드입니다).

지원되는 Python 버전, 최소 지원 Rust 버전(소스에서 Qiskit 빌드 시), Qiskit에서 사용하는 모든 Python 패키지 의존성(의존성의 최소 지원 버전 포함)은 하위 호환성 보장의 일부가 아니며 어떤 출시에서도 변경될 수 있습니다. 부 또는 주요 버전 출시만이 Qiskit 사용 또는 빌드를 위한 최소 요구 사항을 올릴 수 있지만 (새로운 의존성 추가 포함), 패치 수정에는 새로운 Python 버전이나 기타 의존성에 대한 지원이 포함될 수 있습니다. 일반적으로 의존성의 최소 버전은 이전 의존성 버전의 지원이 종료되거나 최신 의존성 릴리스와 이전 버전 간의 호환성을 유지하는 것이 불가능할 때만 증가합니다.

업그레이드 전략

새로운 주요 버전이 출시되면, 권장 업그레이드 경로는 먼저 이전 주요 버전의 가장 최근 부 버전으로 업그레이드하는 것입니다. 새로운 주요 버전 직전에 최종 부 버전이 게시됩니다. 이 최종 부 버전 출시 X.Y+1.0.0은 새로운 주요 버전 시리즈에서 이루어진 API 변경 사항에 대한 경고 및 지원 중단이 포함된 X.Y.0과 동일합니다.

예를 들어, 1.0.0 출시 직전에 0.46.0 출시가 게시됩니다. 0.46.0 출시는 0.45.0 출시와 동일하지만, 1.0.0 출시의 일부로 이루어진 API 변경 사항을 문서화하는 추가 지원 중단 경고가 포함됩니다. 이 패턴은 향후 모든 주요 버전 출시에 사용됩니다.

Qiskit 사용자는 먼저 이 최종 부 버전으로 업그레이드하여 지원 중단 경고를 확인하고 잠재적으로 호환성을 파괴하는 릴리스를 시도하기 전에 Qiskit 사용법을 조정해야 합니다. 이전 주요 버전은 업그레이드할 충분한 시간을 제공하기 위해 최소 6개월 동안 지원됩니다. 이를 관리하는 일반적인 패턴은 최대 버전을 고정하여 호환성을 확인할 때까지 다음 주요 릴리스 시리즈를 사용하지 않는 것입니다. 예를 들어, 현재 주요 Qiskit 버전이 1인 경우 요구 사항 파일에 qiskit<2를 지정하면 API 변경 사항이 없는 버전의 Qiskit을 사용하고 있음을 보장합니다.

버전을 다음 주요 버전보다 낮게 제한하면 주요 버전 출시 전에 지원 중단 경고를 볼 수 있습니다. 제한이 없으면, pip은 기본적으로 사용 가능한 최신 버전을 설치합니다.

QPY 직렬화 형식은 새로운 Qiskit 릴리스가 항상 이전 Qiskit 릴리스로 생성된 QPY 파일을 로드할 수 있도록 하위 호환성이 있습니다. 그러나 형식은 순방향 호환성이 없으므로, 원칙적으로 이전 릴리스를 사용하여 최신 Qiskit 버전으로 생성된 QPY 파일을 로드할 수 없습니다. 주요 버전 출시 간의 사용자 마이그레이션을 용이하게 하기 위해, qiskit.qpy.dump() 함수는 항상 X.0.0X-1.Y.0 릴리스 사이에서 최소 하나의 중복 버전을 지원합니다(여기서 Y는 해당 시리즈의 마지막 부 버전입니다). 매개변수 qiskit.qpy.dump(..., version=...)를 사용하면 새로운 릴리스에서 두 주요 버전 모두에서 로드할 수 있는 QPY 형식 파일을 저장할 수 있습니다. 자세한 내용은 RFC 0020을 참조하세요.

사전 출시

각 부 및 주요 버전 출시에 대해, Qiskit은 PEP440과 호환되는 사전 출시를 게시합니다. 일반적으로 이는 X.Y.0rc1 형식의 출시 후보입니다. rc 출시는 최종화된 API 표면을 가지며 예정된 출시를 테스트하는 데 사용됩니다.

PEP440 사전 출시 접미사(예: a, b, 또는 pre) 중 하나가 게시될 때, 이는 rc 출시와 동일한 보장을 갖지 않으며 미리 보기 출시에 불과합니다. API는 이러한 사전 출시와 해당 버전 번호의 최종 출시 사이에 변경될 수 있습니다. 예를 들어, 1.0.0pre11.0.0과 다른 최종 API를 가질 수 있습니다.

사후 출시

출시의 패키징에 문제가 있는 경우, 이를 수정하기 위해 사후 출시가 발행될 수 있습니다. 이는 X.Y.Z.1 형식을 따르며, 네 번째 정수는 X.Y.Z 출시의 첫 번째 사후 출시임을 나타냅니다. 예를 들어, qiskit-terra(Qiskit의 레거시 패키지 이름) 0.25.2 출시에는 sdist 패키지 게시와 관련된 문제가 있었으며, 이 문제를 수정한 사후 출시 0.25.2.1이 게시되었습니다. 코드는 동일하였으며, 0.25.2.1은 출시의 패키징 문제만 수정하였습니다.

기여자가 지원 중단을 표시하는 방법

소스 코드에 지원 중단을 추가하는 방법에 대한 지침은 Qiskit SDK 저장소의 지원 중단 가이드를 참조하세요.