PEP 6: バグ修正リリース

原文:http://www.python.org/dev/peps/pep-0006/

PEP 6
Title Bug Fix Releases
Version $Revision$
Last-Modified $Date$
Author aahz@pythoncraft.com(Aahz),anthony@interlink.com.au(AnthonyBaxter)
Status Active
Type Process
Created 15-Mar-2001
Post-History 15-Mar-2001 18-Apr-2001 19-Aug-2004

概要

Pythonは歴史的に、分岐せず開発主体は一つだけ、この開発主体が新しい機能を追加したものとバグの修正とを組み合わせたバージョンをリリースします(これらのリリースは”メジャーリリース”とされます)。このPEPは、どのように管理やバグ修正を分岐(fork)するか、バグを修正する事を第一の目的とした古いバージョンをリリースするかについて述べます。(訳注: 自信無)

このPEPは、バグ修正のためのリリースが存在する事を保証するものではありません。繰り返します。バグ修正リリースを保証するものではありません。もし、Pythonコミュニティの中で十分多くの人がバグ修正リリースを望んだ場合に、そのための作業が以下の手続きに従って行われます。

モチベーション

SourceForgeに移動してから、Pythonの開発は加速されました。これに対してコミュニティの一部からは加速されすぎているという意見があり、また、あまりに多くの機能が新しいバージョンに付け加えられた時に、時としてバグ修正が開発サイクルの中で遅れてしまうことに、多くの人々が困惑しています。(訳注: 自信無)

一つの解決方法は、一つ前のメジャーリリースをメンテナンスして次のメジャーリリースがデルまでの間バグ修正を提供しつづけることです。これは、Pythonを数百数千のマシンにインストールする必要があるエンタープライズ向け開発に対して魅力あるものにします。

禁止事項

バグ修正リリースは以下の制限を守らなくてはいけません。

  1. 文法の変更をしてはいけません。全ての.pyc と.pyoファイルは(再生成の必要なく)メジャーリリースから分岐した全てのバグ修正リリースで動作する必要があります。
  1. 問題がある変更であってはいけません。
  1. C APIに互換性がない変更があってはいけません。メジャーリリースから分岐した全てのバグ修正リリースにおいて、全ての拡張機能はコンパイルすることなく動かなくてはいけません。

    BDFLからの宣言があれば(かつ、リリースノートに目立つように書いてあれば)、この禁止事項を破ることができます。

準禁止事項(訳注:正しい訳か自信無)

可能であれば、バグ修正リリースは以下の事項に従います。

  1. 新しい機能の追加をしない。バグ修正リリースの目的はバグを修正することであり、CVS RootのHEADから最新で超すごい機能を付け加えることではありません。
  1. 苦痛のない更新であること。ユーザは2.x.yから2.x.(y+1)に更新したときに、今現在動いているシステムが壊れないという確信を持てる必要があります。この意味は、バグ修正に必要がない限り、標準ライブラリの振る舞いや最低限APIを変更しないようにする、ということです。

適用する禁止事項

上記禁止事項と準禁止事項は、最終リリースに対するバグ修正リリース(例: 2.4から2.4.1)と、あるバグ修正リリースと次のシリーズ(例: 2.4.1から2.4.2)の両方に対して摘要されます。

このPEPに記されている禁止事項は、問題なく、安全なバグ更新リリースをコミュニティに提供することに役立つでしょう。

バグ修正リリースを助けるには

バグ修正リリースのプロセスを助けるいくつかの方法を記します。

1. バグフィックスをバックポートすること。もしあなたがバグを直し、それが適切であれば、現在のバグ修正リリースのCVSブランチに移植してください。もしあなたが自分でバックポートしたくない、あるいはできないのであれば、コミットメッセージに”バグ修正候補(Bugfix candidate)”や”バックポート候補(Backportcandidate)”と注意書きを残してください。

もし不安があれば、聞いてください。もし、ある特殊な修正が正しいと思うのであれば(訳注:自信無)現在のバグ修正リリースを管理している人に聞いてください。

もし、特殊なバグがあり、バグ修正リリースで修正された場合、飛び跳ねて(訳注:別な意味がある?)終わらせようとしてください。バグ修正リリースが公開されるまでの48時間以内であれば、バグ修正リリースに含めるようにお願いすることができます。

バージョン番号

Python 2.0から、全てのメジャーリリースは X.Yという形式のバージョン番号をつけられます。バグ修正リリースは、X.Y.Zという形式です。

現在開発中のメジャーリリースはリリース番号Nと呼ばれます。一番最近リリースされたメジャーリリースはN-1と呼ばれます。

CVSにおいて、バグ修正リリースはブランチの上でリリースされます。リリース2.xに対してブランチは’release2x-maint’と名前をつけられます。例えば、2.3に対するメンテナンスリリースは’release23-maint’です。

手続き

バグ修正リリースのプロセスはTcl system[1]を一部手本としました。

Patch Czarはバグ修正リリースにおいてBDFLの対応する人です。しかし、BDFLと任命された人はそれぞれのパッチに対して拒否権を持っています。Path Czarは開発ブランチ一つだけを担当します。つまり、2.3.xと2.4.xを別の人が担当することはよくあることなのです。

それぞれのパッチはCVSの現在のtrunkに対して適用され、それぞれのパッチのコミッターは、そのパッチがバグ修正リリースに含むべき修正なのかを考えることを求められます。コミッターはリリースからメンテナンスブランチにコミットするか、コミットメッセージの中のパッチにマークすることができます。(訳注:パッチに関する知識がなくて不明瞭)

付け加えると、Pythonコミュニティの誰でもが、あるパッチをリリースに含めるように提案できます。パッチはバグ修正リリースにのみ申請されることがあります。提案する人は PEP 3[2]のガイドラインに従う必要があります。一般的に、ブランチと同じようにHEADでもそのバグは修正されます。

Path Czarはリリースの品質を保証するに足る十分な数のパッチが集まった時に、決断を下します。リリースはパッケージ化され、Windowsインストーラを含み、公開されます。もし、新たなバグが見つかった場合、すぐに修正され、(バージョン番号が上がった)新しいバグ修正リリースとして公開されます。2.3.xのリリースサイクルでは、Path Czar(Anthony)は約6ヵ月ごとにリリースしようとしていますが、将来のリリースでも同じとは限りません。

バグ修正リリースはだいたい6ヶ月の間隔をおくとされています。これは単なるガイドラインではありますが、しかし、もし大きなバグが見つかった場合、バグ修正リリースはすぐにリリースされるでしょう。一般的に行って、どんなときもN-1のリリースは現在メンテナンスされているブランチで行われます。つまり、Python 2.4の開発中、Python 2.3がバグ修正リリースとなります。しかし、もし、誰かが古いリリースも管理しつづけたいと願った場合、その人は他の人を説得しなければならないでしょう。

Patch Czarの歴史

Anthony Baxterが2.3.1から2.3.4までPatch Czarでした。

Barry Warsawが2.2.3でPatch Czarでした。

Guido van Rossumが2.2.2でPatch Czarでした。

Michael Hudsonが2.2.1でPatch Czarでした。

Anthony Baxterが2.1.2と2.1.3でPatch Czarでした。

Thomas Woutersが2.1.1でPatch Czarでした。

Moshe Zadkaが2.0.1でPatch Czarでした。

歴史

このPEPは comp.lang.pythonで、提案として生まれました。オリジナルバージョンはNリリースと同時にリリースする、N-1リリースに対する一つのパッチを提案していました。また、オリジナルバージョンは厳密なバグ修正ポリシーについて議論されました。

BDFLや他の人からのフィードバックに従い、PEPの草稿では、以前の全てのメジャーバージョンからパッチを含めるという拡張されたバグ修正リリースのサイクルを含み、また、厳密なバグ修正要求(主にバグ修正と機能の両方に対する議論をさせるPEP 235[3]の例による)を緩めるようになりました。

議論はほとんどpython-devに移行し、BDFLはPythonのバグ修正リリースはTclを元にすると宣言しました。それは、N-1リリースはバグ修正だけしか受け付けないが、Nがリリースされるまで複数のバグ修正リリースが出せるというオリジナルの提案に戻ったものでした。

その後、Anthony BaxterがこのPEPを取り上げ、2.3のリリースサイクルで学んだことに基づいて、改訂しました。

参考文献

[1]http://www.tcl.tk/cgi-bin/tct/tip/28.html

[2] PEP 3, Guidelines for Handling Bug Reports, Hylton
http://www.python.org/dev/peps/pep-0003/
[3] PEP 235, Import on Case-Insensitive Platforms, Peters
http://www.python.org/dev/peps/pep-0235/

著作権

このドキュメントはパブリック・ドメインに属します。

Local Variables:coding: utf-8End:

Table Of Contents

Previous topic

PEP 5: 言語開発のガイドライン

Next topic

PEP 9: テキストでのPEPテンプレートの例(不完全)

This Page