リリース・ポリシー

:CategoryDev

リリース・ポリシー†

DRAFT

This page is not complete.
このページは草案です。

関連†

• official:History
• ロードマップ/過去の話題
• ロードマップ
• 開発談義/8（2004-07-07 (水) 09:00:15の投稿あたり）
• 開発談義/1.3のサポート
• 開発談義
• BugTrack2/12（1.4は、今でも開発ブランチなのか？）
• BugTrack2/228（リリース頻度とメジャーバージョンについて）
• BugTrack/556（ファイルリリースを廃止して、全てのユーザーにCVS版を使わせるべきか？）

リリース†

リリースの条件†

正式なリリースとして広く利用を呼びかけるようなものであれば、利用者にシステムの入れ替えを行わせられるほどの説得力を持った、万人向けの改善がそれなりに必要である。

リリース頻度†

• 一般的には、[早すぎず、遅すぎず*1]、[意味のある*2]リリースを行うのが良いと言われているかと思います(条件は他にもあります)。
  • *1 特にオープンソースソフトウェアについては、レビューとフィードバックの頻度を増やすという観点で、多頻度が良いと言われる
  • *2 内容が相応に濃いリリースは更新を促す

PukiWikiというプロダクトとその利用者について言えば、数ヶ月(三ヶ月以上)に一回あたりが適当と考えます。六ヶ月は長すぎだし一ヶ月は短すぎです。
数ヶ月に一回程度であれば、管理者がPukiWikiの入れ替えに関心を持つ機会としても、我々がリリースについて考える頻度(負担：リリースのためにテストをしたり、ドキュメントをまとめたりするリリースエンジニアリング作業)としても折り合いが付くと考えています。

ブランチ†

開発ブランチ(trunk)について†

• 他のプロダクトと同様に、最前線の開発ブランチでは積極的に改変を加え、落ち着いたころにリリースするというサイクルを繰り返します。
  1. リリースの直後には大規模な変更が増え、逆にリリース前には安定化とバランス調整の作業がが増えます。
  2. 実験的なコードに不都合があればリリースまでに破棄するものもあるでしょう。
  3. 最適解を求めて右往左往することもあるでしょう。
  4. コードを強引にクリンナップすることもあるでしょう。
• それが未来を現実をにするというのが、このブランチの役目です。
  • ユーザーデータに関する互換性は基本的に守られますが、コードの中身やファイル構成などの無駄は大幅に整理されることがあります。

メンテナンスブランチについて†

• 長期安定運用を現実にするのがこのブランチの役目です。
  • ユーザーデータに関する互換性は必ずと言っていいほど守られます。
  • コードの中身やファイル構成などの無駄は整理されることがあります。
  • また、次の世代へ移行する手順は基本的に変化しません。
• セキュリティ関係のバグフィックス以外は(原則として)行なわない。機能拡張はもちろんのこと、通常のバグについてはサポートしない。

安定版・開発版、CVS版について†

安定版

ユーザーに公開することを意識してリリースしたものは安定版

開発版

開発ブランチの開発途中のもの

CVS版

PukiWikiの場合「開発ブランチから任意のタイミングで取り出したもの

PukiWikiに限らず、一本の開発ブランチで作業しているプロジェクトは全て不安定な状態と安定な状態を行き来します。
一般ユーザーの視点で言うと、リリースとリリースの合間は、何かしら不安定な状態(開発日記とソースを読み解く以外にはわかりやすい説明はありません)になります。（図1）

図1
|----------------------- CVS版 (1.4.x開発ブランチ) -------------------->|
======開発版=====> 安定版(1.4.5) =====開発版=====> 安定版(1.4.5_1) ====>
※安定版と呼べる状態は、それぞれほんの一瞬のみ

仮に安定版のリリース毎に、個々の安定版をメンテナンスするためのブランチ(専用のソースツリー)を用意する場合、下記（図2）のようにソースが分岐します。
1.4.5のためのメンテナンス専用ブランチは、メンテナンスだけの最低限の作業だけを行う様にする様にします。 このような運営を行っている時でも、CVSで管理しているソースの任意の一瞬を取り出したものは全て不安定版です。 メンテナンスのためのブランチが stable ブランチと呼ばれることはありますが、そのブランチにあるものが全て安定だということまでは保証できません。 安定版と呼べるのは実際にリリース作業を通して発表されたものだけです。

図2
|----------------------- CVS版 (1.4.x開発ブランチ) -------------------->|
====開発版(1.4.5_alpha)====> 安定版(1.4.5) ====開発版(1.4.6_alpha)===>
                                |===========> 安定版(1.4.5_1) =========>
                               分岐 (1.4.5メンテナンスブランチ)
※安定版と呼べる状態は、それぞれほんの一瞬のみ

バージョン†

バージョンアップの定義†

メジャーバージョン

非互換性が含まれていることを暗示させるために行います。

マイナーバージョン

(上位あるいは同等の)互換性が保たれていることを暗示させるために行います。

バージョン定義†

※バージョン定義については、以下の様な認識であり、意見合わせが出来ていません。

ロードマップ/過去の話題より

(PukiWiki n.n.n という数字の何がメジャーかどうかというのはさておき、
メジャー番号の違いが示唆するのは「徹底的な''内部構造の''非互換」です)
 -- [[henoheno]] &new{2004-10-24 (日) 15:35:09};

-さて、何をもって 1.3 や 1.4 や 1.5 や 2.0 であるのか、
あるいは何がメジャーバージョンでマイナーバージョンなのか、
各人の希望が実情と合っているのかどうか、といった話を含め、
開発とメンテナンスとリリースに関する認識について意見交換をした方が良さそうな感じですね :)
-- [[henoheno]] &new{2004-10-24 (日) 15:35:23};

その他バージョン定義†

• n.n.n rc x
  • rc xのxには数字が入ります。
  • 例 1.4.4rc1
  • Release candidate(リリース候補)の意味

• n.n.n_xxx
  • _xxxには名称が入ります。
  • 例 1.4.7_php5
  • 次期リリースで導入しようとしていた”1つの機能”を前倒しでリリースしたもの

• n.n.n_x
  • _xには数字が入ります。
  • 例 1.4.5_1
  • 次期リリースで導入しようとしていた”一部または複数の機能”を前倒しでリリースしたもの

• n.n.n_notb
  • _notbの名称が最後に付きます。
  • 例 1.4.7_notb
  • コードまたはファイル削除を必用とする深刻な問題に対処しリリースしたもの

バージョン番号の繰り上がりについて†

PukiWikiプロジェクトは、マイナーバージョンの繰り上がり(=リリース頻度)が、メジャーバージョンに影響を与えるという事はありません。
仮に 1.4.9 の次があるとしたら、1.4.10 のようになります。

時として、マイナーバージョンの桁上がりを一つの区切りとみなしてメジャーバージョンが更新される事はありますが、メジャーバージョンの意味合いを明確にする事による恩恵を受けているプロジェクトでは、脈絡のないメジャーバージョンの更新はデメリットの方が多くなるでしょう。こうした表現は Linux 0.99.10（最初のバージョンは Linux(freax) 0.01 であるため、0.10は今回の例には当てはまらない。1.0のリリースまでに10回以上99回までの更新が意図されていたようだが、結果としては0.99まで行った後、1年以上粘って1.0になった。この例でも、メジャーバージョンはとても意識されている）、FreeBSD 4.10、(OpenSSHが生まれる前の)ssh, glib, OpenLDAP、その他特定の製品をターゲットにした10回目のパッチ・・・等々、以前から行われています。

コメント†

(ここからのコメントは、コメント/開発談義 過去ログの開発談義/10 より移動)

• 各ユーザーがリリースやバージョン定義等について、これからの意見合わせの基礎となる一定の認識を持つためのページが必用であると考え、リリース・ポリシーという公文書草案を作成しました。引用元を関連に記載しています。少し変更している点がありますが、主にhenohenoさんの発言からの引用です。現状と異なる点がありましたら変更及び修正をお願いします。問題が無いようでしたら、現状のルールと言うことでDRAFTの文言を削除して下さい。その上で意見合わせが出来ればと思います。 -- 2010-08-21 (土) 14:11:33
• お疲れ様です。この手の概念には先例があります。 -- henoheno 2010-08-23 (月) 07:10:30
  • http://www.freebsd.org/releng/
  • http://releng.netbsd.org/
  • http://www.gentoo.org/proj/en/releng/
  • http://wiki.eclipse.org/Linux_Tools_Project/Releng

• リリース・ポリシーは先例がありますということで不採用なのでしょうか？ -- 匿名３ 2010-09-18 (土) 11:55:24
  • こんにちは。こちらは説明(既存コンテンツ）のまとめなので、ポリシーという言葉を含まない別のページ名が良いのではないでしょうか。通常のまとめBugTrackでも良いと思いましたがいかがでしょうか。 -- henoheno 2010-09-21 (火) 06:52:37
    • アップされた方は、このプロジェクトが好きで、おそらくそれなりの時間をかけて、このドキュメントをまとめられています。このサイトの方針とぶれているならそれを指摘し、そうでないならもう少し分かりやすいコメントを付け(ぶれてないならドラフトを外し、サイトの方針としてもよいのではと思います)、アップした人が次のアクションをとりやすいようにしてあげたほうがいいのではないかと思います。そうでないとせっかくの協力者がこのサイトから離れて行ってしまうのではと心配しています。 -- 匿名３ 2010-09-23 (木) 21:48:40
    • こんにちは。追記ありがとうございます。匿名３さんが上記ページの書き手でない、という点について了解しました。書き手さんとやりとりしたかったので、書き手さんによるコメントと誤認しておりました。 -- henoheno 2010-09-28 (火) 23:34:39
  • リリースポリシーという言葉に反応して、リリースエンジニアリングに関する先例をいくつか示して様子見となっていましたが、ページ名から与える印象(リリースのポリシー)と内容(まとめ)のずれが大きいため、「ポリシーという言葉を含まない別のページ名が良いのではないでしょうか。通常のまとめBugTrackでも良いと思いましたがいかがでしょうか。」というアクションをするのがロスが少ない様に思います。で、それについて匿名３さんはどう思いますか？ (この話題、後でまとめて該当ページに移動しましょう) -- henoheno 2010-09-28 (火) 23:34:54
    • 私は該当ページの作成者の仕事が無視されなければどのような形であれOKかと思います。さしでがましいことをしました。この名前での投稿はこれで最後にします。 -- 匿名３ 2010-09-29 (水) 18:07:39

(ここまで、開発談義/10より移動)

• BugTrack
• 開発版
  • リポジトリ
  • 開発日記
• :CategoryDev
  • PukiWiki2
  • PukiWiki/1.5
  • PukiWiki/1.4
  • PukiWiki/1.3
  • メーリングリスト
  • 開発談義
  • 雑談
• 開発者向け情報
  • Books
  • プラグイン

最新の16件