リリースプロセスとルール
バージョンv2.6.2の新機能。
v2.6.2以降にリリースされるバージョンから、次のルールが、Requestsコアチームが新しいリリースを作成する方法を管理および説明します。
メジャーリリース
メジャーリリースには、重大な変更が含まれます。 バージョン管理されると、vX.0.0としてバージョン管理されます。 たとえば、前のリリースがv10.2.7だった場合、次のバージョンはv11.0.0になります。
重大な変更とは、以前のバージョンとの下位互換性を損なう変更です。 プロジェクトがResponseオブジェクトのtext属性をメソッドに変更する場合、それはメジャーリリースでのみ発生します。
メジャーリリースには、その他のバグ修正も含まれる場合があります。 Requestsのコア開発者は、優れたユーザーエクスペリエンスの提供に取り組んでいます。 これは、下位互換性を可能な限り維持することにも取り組んでいることを意味します。 メジャーリリースはまれであり、検討される前に強力な正当化が必要になります。
マイナーリリース
マイナーリリースには重大な変更は含まれませんが、その他のバグ修正が含まれる場合があります。 以前にリリースされたリクエストのバージョンがv10.2.7の場合、マイナーリリースはv10.3.0としてバージョン管理されます。
マイナーリリースは、同じメジャーバージョン番号を持つリリースと下位互換性があります。 つまり、v10.で始まるすべてのバージョンは相互に互換性がある必要があります。
修正プログラムのリリース
ホットフィックスリリースには、プロジェクトが以前のバージョンをリリースしたときに見逃されていたバグ修正のみが含まれます。 以前のバージョンのリクエストがv10.2.7をリリースした場合、修正プログラムリリースはv10.2.8としてバージョン管理されます。
修正プログラムには、v2.6.2以降のベンダー依存関係へのアップグレードは含まれません。
推論
2.5および2.6リリースシリーズでは、Requestsコアチームがベンダーの依存関係をアップグレードし、ユーザーとコアチームの両方に大きな頭痛の種を引き起こしました。 この痛みを軽減するために、期待が適切に設定されるように、具体的な一連の手順を作成しています。
