原文: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を数百数千のマシンにインストールする必要があるエンタープライズ向け開発に対して魅力あるものにします。
バグ修正リリースは以下の制限を守らなくてはいけません。
C APIに互換性がない変更があってはいけません。メジャーリリースから分岐した全てのバグ修正リリースにおいて、全ての拡張機能はコンパイルすることなく動かなくてはいけません。
BDFLからの宣言があれば(かつ、リリースノートに目立つように書いてあれば)、この禁止事項を破ることができます。
可能であれば、バグ修正リリースは以下の事項に従います。
上記禁止事項と準禁止事項は、最終リリースに対するバグ修正リリース(例: 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がバグ修正リリースとなります。しかし、もし、誰かが古いリリースも管理しつづけたいと願った場合、その人は他の人を説得しなければならないでしょう。
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