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 | +---------------+-----------------------------------------+ .. Abstract --------- 概要 --------- .. Python has historically had only a single fork of development, with releases having the combined purpose of adding new features and delivering bug fixes (these kinds of releases will be referred to as "major releases"). This PEP describes how to fork off maintenance, or bug fix, releases of old versions for the primary purpose of fixing bugs. Pythonは歴史的に、分岐せず開発主体は一つだけ、この開発主体が新しい機能を 追加したものとバグの修正とを組み合わせたバージョンをリリースします(これら のリリースは"メジャーリリース"とされます)。このPEPは、どのように管理やバ グ修正を分岐(fork)するか、バグを修正する事を第一の目的とした古いバージョ ンをリリースするかについて述べます。(訳注: 自信無) .. This PEP is not, repeat NOT, a guarantee of the existence of bug fix releases; it only specifies a procedure to be followed if bug fix releases are desired by enough of the Python community willing to do the work. このPEPは、バグ修正のためのリリースが存在する事を保証するものではありませ ん。繰り返します。バグ修正リリースを保証するものではありません。もし、 Pythonコミュニティの中で十分多くの人がバグ修正リリースを望んだ場合に、そ のための作業が以下の手続きに従って行われます。 .. Motivation ------------- モチベーション ----------------- .. With the move to SourceForge, Python development has accelerated. There is a sentiment among part of the community that there was too much acceleration, and many people are uncomfortable with upgrading to new versions to get bug fixes when so many features have been added, sometimes late in the development cycle. SourceForgeに移動してから、Pythonの開発は加速されました。これに対してコミュ ニティの一部からは加速されすぎているという意見があり、また、あまりに多く の機能が新しいバージョンに付け加えられた時に、時としてバグ修正が開発サイ クルの中で遅れてしまうことに、多くの人々が困惑しています。(訳注: 自信無) .. One solution for this issue is to maintain the previous major release, providing bug fixes until the next major release. This should make Python more attractive for enterprise development, where Python may need to be installed on hundreds or thousands of machines. 一つの解決方法は、一つ前のメジャーリリースをメンテナンスして次のメジャー リリースがデルまでの間バグ修正を提供しつづけることです。これは、Pythonを 数百数千のマシンにインストールする必要があるエンタープライズ向け開発に対 して魅力あるものにします。 .. Prohibitions ------------- 禁止事項 ------------- .. Bug fix releases are required to adhere to the following restrictions: バグ修正リリースは以下の制限を守らなくてはいけません。 .. 1. There must be zero syntax changes. All .pyc and .pyo files must work (no regeneration needed) with all bugfix releases forked off from a major release. 1. 文法の変更をしてはいけません。全ての.pyc と.pyoファイルは(再生成の必要 なく)メジャーリリースから分岐した全てのバグ修正リリースで動作する必要 があります。 .. 2. There must be zero pickle changes. 2. 問題がある変更であってはいけません。 .. 3. There must be no incompatible C API changes. All extensions must continue to work without recompiling in all bugfix releases in the same fork as a major release. .. Breaking any of these prohibitions requires a BDFL proclamation (and a prominent warning in the release notes). 3. C APIに互換性がない変更があってはいけません。メジャーリリースから分岐 した全てのバグ修正リリースにおいて、全ての拡張機能はコンパイルすることな く動かなくてはいけません。 BDFLからの宣言があれば(かつ、リリースノートに目立つように書いてあれば)、 この禁止事項を破ることができます。 .. Not-Quite-Prohibitions -------------------------- 準禁止事項(訳注:正しい訳か自信無) ---------------------------------- .. Where possible, bug fix releases should also: 可能であれば、バグ修正リリースは以下の事項に従います。 .. 1. Have no new features. The purpose of a bug fix release is to fix bugs, not add the latest and greatest whizzo feature from the HEAD of the CVS root. 1. 新しい機能の追加をしない。バグ修正リリースの目的はバグを修正すること であり、CVS RootのHEADから最新で超すごい機能を付け加えることではあり ません。 .. 2. Be a painless upgrade. Users should feel confident that an upgrade from 2.x.y to 2.x.(y+1) will not break their running systems. This means that, unless it is necessary to fix a bug, the standard library should not change behavior, or worse yet, APIs. 2. 苦痛のない更新であること。ユーザは2.x.yから2.x.(y+1)に更新したときに、 今現在動いているシステムが壊れないという確信を持てる必要があります。こ の意味は、バグ修正に必要がない限り、標準ライブラリの振る舞いや最低限 APIを変更しないようにする、ということです。 .. Applicability of Prohibitions 適用する禁止事項 --------------------------------------- .. The above prohibitions and not-quite-prohibitions apply both for a final release to a bugfix release (for instance, 2.4 to 2.4.1) and for one bugfix release to the next in a series (for instance 2.4.1 to 2.4.2). 上記禁止事項と準禁止事項は、最終リリースに対するバグ修正リリース(例: 2.4 から2.4.1)と、あるバグ修正リリースと次のシリーズ(例: 2.4.1から2.4.2)の両 方に対して摘要されます。 .. Following the prohibitions listed in this PEP should help keep the community happy that a bug fix release is a painless and safe upgrade. このPEPに記されている禁止事項は、問題なく、安全なバグ更新リリースをコミュ ニティに提供することに役立つでしょう。 .. Helping the Bug Fix Releases Happen ------------------------------------- バグ修正リリースを助けるには ------------------------------------- .. Here's a few pointers on helping the bug fix release process along. バグ修正リリースのプロセスを助けるいくつかの方法を記します。 .. 1. Backport bug fixes. If you fix a bug, and it seems appropriate, port it to the CVS branch for the current bug fix release. If you're unwilling or unable to backport it yourself, make a note in the commit message, with words like 'Bugfix candidate' or 'Backport candidate'. 1. バグフィックスをバックポートすること。もしあなたがバグを直し、それが適 切であれば、現在のバグ修正リリースのCVSブランチに移植してください。もしあ なたが自分でバックポートしたくない、あるいはできないのであれば、コミット メッセージに"バグ修正候補(Bugfix candidate)"や"バックポート候補(Backport candidate)"と注意書きを残してください。 .. 2. If you're not sure, ask. Ask the person managing the current bug fix releases if they think a particular fix is appropriate. もし不安があれば、聞いてください。もし、ある特殊な修正が正しいと思うので あれば(訳注:自信無)現在のバグ修正リリースを管理している人に聞いてください。 .. 3. If there's a particular bug you'd particularly like fixed in a bug fix release, jump up and down and try to get it done. Do not wait until 48 hours before a bug fix release is due, and then start asking for bug fixes to be included. もし、特殊なバグがあり、バグ修正リリースで修正された場合、飛び跳ねて(訳 注:別な意味がある？)終わらせようとしてください。バグ修正リリースが公開さ れるまでの48時間以内であれば、バグ修正リリースに含めるようにお願いするこ とができます。 .. Version Numbers ---------------- バージョン番号 ---------------- .. Starting with Python 2.0, all major releases are required to have a version number of the form X.Y; bugfix releases will always be of the form X.Y.Z. Python 2.0から、全てのメジャーリリースは X.Yという形式のバージョン番号を つけられます。バグ修正リリースは、X.Y.Zという形式です。 .. The current major release under development is referred to as release N; the just-released major version is referred to as N-1. 現在開発中のメジャーリリースはリリース番号Nと呼ばれます。一番最近リリー スされたメジャーリリースはN-1と呼ばれます。 .. In CVS, the bug fix releases happen on a branch. For release 2.x, the branch is named 'release2x-maint'. For example, the branch for the 2.3 maintenance releases is release23-maint CVSにおいて、バグ修正リリースはブランチの上でリリースされます。リリース 2.xに対してブランチは'release2x-maint'と名前をつけられます。例えば、2.3に 対するメンテナンスリリースは'release23-maint'です。 .. Procedure --------------- 手続き --------------- .. The process for managing bugfix releases is modeled in part on the Tcl system [1]. バグ修正リリースのプロセスはTcl system[1]を一部手本としました。 .. The Patch Czar is the counterpart to the BDFL for bugfix releases. However, the BDFL and designated appointees retain veto power over individual patches. A Patch Czar might only be looking after a single branch of development - it's quite possible that a different person might be maintaining the 2.3.x and the 2.4.x releases. Patch Czarはバグ修正リリースにおいてBDFLの対応する人です。しかし、BDFLと 任命された人はそれぞれのパッチに対して拒否権を持っています。Path Czarは開 発ブランチ一つだけを担当します。つまり、2.3.xと2.4.xを別の人が担当するこ とはよくあることなのです。 .. As individual patches get contributed to the current trunk of CVS, each patch committer is requested to consider whether the patch is a bug fix suitable for inclusion in a bugfix release. If the patch is considered suitable, the committer can either commit the release to the maintenance branch, or else mark the patch in the commit message. それぞれのパッチはCVSの現在のtrunkに対して適用され、それぞれのパッチのコ ミッターは、そのパッチがバグ修正リリースに含むべき修正なのかを考えること を求められます。コミッターはリリースからメンテナンスブランチにコミットす るか、コミットメッセージの中のパッチにマークすることができます。(訳注:パッ チに関する知識がなくて不明瞭) .. In addition, anyone from the Python community is free to suggest patches for inclusion. Patches may be submitted specifically for bugfix releases; they should follow the guidelines in PEP 3 [2]. In general, though, it's probably better that a bug in a specific release also be fixed on the HEAD as well as the branch. 付け加えると、Pythonコミュニティの誰でもが、あるパッチをリリースに含める ように提案できます。パッチはバグ修正リリースにのみ申請されることがありま す。提案する人は PEP 3[2]のガイドラインに従う必要があります。一般的に、ブ ランチと同じようにHEADでもそのバグは修正されます。 .. The Patch Czar decides when there are a sufficient number of patches to warrant a release. The release gets packaged up, including a Windows installer, and made public. If any new bugs are found, they must be fixed immediately and a new bugfix release publicized (with an incremented version number). For the 2.3.x cycle, the Patch Czar (Anthony) has been trying for a release approximately every six months, but this should not be considered binding in any way on any future releases. Path Czarはリリースの品質を保証するに足る十分な数のパッチが集まった時に、 決断を下します。リリースはパッケージ化され、Windowsインストーラを含み、公 開されます。もし、新たなバグが見つかった場合、すぐに修正され、(バージョン 番号が上がった)新しいバグ修正リリースとして公開されます。2.3.xのリリース サイクルでは、Path Czar(Anthony)は約6ヵ月ごとにリリースしようとしていま すが、将来のリリースでも同じとは限りません。 .. Bug fix releases are expected to occur at an interval of roughly six months. This is only a guideline, however - obviously, if a major bug is found, a bugfix release may be appropriate sooner. In general, only the N-1 release will be under active maintenance at any time. That is, during Python 2.4's development, Python 2.3 gets bugfix releases. If, however, someone qualified wishes to continue the work to maintain an older release, they should be encouraged. バグ修正リリースはだいたい6ヶ月の間隔をおくとされています。これは単なるガ イドラインではありますが、しかし、もし大きなバグが見つかった場合、バグ修 正リリースはすぐにリリースされるでしょう。一般的に行って、どんなときも N-1のリリースは現在メンテナンスされているブランチで行われます。つまり、 Python 2.4の開発中、Python 2.3がバグ修正リリースとなります。しかし、もし、 誰かが古いリリースも管理しつづけたいと願った場合、その人は他の人を説得し なければならないでしょう。 .. Patch Czar History Patch Czarの歴史 ------------------ .. Anthony Baxter is the Patch Czar for 2.3.1 through 2.3.4. Anthony Baxterが2.3.1から2.3.4までPatch Czarでした。 .. Barry Warsaw is the Patch Czar for 2.2.3. Barry Warsawが2.2.3でPatch Czarでした。 .. Guido van Rossum is the Patch Czar for 2.2.2. Guido van Rossumが2.2.2でPatch Czarでした。 .. Michael Hudson is the Patch Czar for 2.2.1. Michael Hudsonが2.2.1でPatch Czarでした。 .. Anthony Baxter is the Patch Czar for 2.1.2 and 2.1.3. Anthony Baxterが2.1.2と2.1.3でPatch Czarでした。 .. Thomas Wouters is the Patch Czar for 2.1.1. Thomas Woutersが2.1.1でPatch Czarでした。 .. Moshe Zadka is the Patch Czar for 2.0.1. Moshe Zadkaが2.0.1でPatch Czarでした。 .. History 歴史 ----- .. This PEP started life as a proposal on comp.lang.python. The original version suggested a single patch for the N-1 release to be released concurrently with the N release. The original version also argued for sticking with a strict bug fix policy. このPEPは comp.lang.pythonで、提案として生まれました。オリジナルバージョ ンはNリリースと同時にリリースする、N-1リリースに対する一つのパッチを提案 していました。また、オリジナルバージョンは厳密なバグ修正ポリシーについて 議論されました。 .. Following feedback from the BDFL and others, the draft PEP was written containing an expanded bugfix release cycle that permitted any previous major release to obtain patches and also relaxed the strict bug fix requirement (mainly due to the example of PEP 235 [3], which could be argued as either a bug fix or a feature). BDFLや他の人からのフィードバックに従い、PEPの草稿では、以前の全てのメジャー バージョンからパッチを含めるという拡張されたバグ修正リリースのサイクルを 含み、また、厳密なバグ修正要求(主にバグ修正と機能の両方に対する議論をさせ るPEP 235[3]の例による)を緩めるようになりました。 .. Discussion then mostly moved to python-dev, where BDFL finally issued a proclamation basing the Python bugfix release process on Tcl's, which essentially returned to the original proposal in terms of being only the N-1 release and only bug fixes, but allowing multiple bugfix releases until release N is published. 議論はほとんどpython-devに移行し、BDFLはPythonのバグ修正リリースはTclを元 にすると宣言しました。それは、N-1リリースはバグ修正だけしか受け付けないが、 Nがリリースされるまで複数のバグ修正リリースが出せるというオリジナルの提案 に戻ったものでした。 .. Anthony Baxter then took this PEP and revised it, based on lessons from the 2.3 release cycle. その後、Anthony BaxterがこのPEPを取り上げ、2.3のリリースサイクルで学んだ ことに基づいて、改訂しました。 .. References 参考文献 --------- [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/ .. Copyright 著作権 ------- .. This document has been placed in the public domain. このドキュメントはパブリック・ドメインに属します。 Local Variables: coding: utf-8 End: