[[:CategoryDev]]
*リリース・ポリシー [#m1d4e172]
:DRAFT|This page is not complete.~
このページは草案です。
----
#contents
----
**関連 [#o6015f07]
-[[official:History]]
-[[ロードマップ/過去の話題]]
-[[ロードマップ]]
-[[開発談義/8]]（2004-07-07 (水) 09:00:15の投稿あたり）
-[[開発談義/1.3のサポート]]
-[[開発談義]]
-[[BugTrack2/12]]（1.4は、今でも開発ブランチなのか？）
-[[BugTrack2/228]]（リリース頻度とメジャーバージョンについて）
-[[BugTrack/556]]（ファイルリリースを廃止して、全てのユーザーにCVS版を使わせるべきか？）
----
**リリース [#m08f20ef]
***リリースの条件 [#oaaadeb5]
正式なリリースとして広く利用を呼びかけるようなものであれば、利用者にシステムの入れ替えを行わせられるほどの説得力を持った、万人向けの改善がそれなりに必要である。
***リリース頻度 [#fff1fb84]
-一般的には、[早すぎず、遅すぎず*1]、[意味のある*2]リリースを行うのが良いと言われているかと思います(条件は他にもあります)。
--*1 特にオープンソースソフトウェアについては、レビューとフィードバックの頻度を増やすという観点で、多頻度が良いと言われる
--*2 内容が相応に濃いリリースは更新を促す
PukiWikiというプロダクトとその利用者について言えば、数ヶ月(三ヶ月以上)に一回あたりが適当と考えます。六ヶ月は長すぎだし一ヶ月は短すぎです。~
数ヶ月に一回程度であれば、管理者がPukiWikiの入れ替えに関心を持つ機会としても、我々がリリースについて考える頻度(負担：リリースのためにテストをしたり、ドキュメントをまとめたりするリリースエンジニアリング作業)としても折り合いが付くと考えています。
----
**ブランチ [#x851d7dd]
***開発ブランチ(trunk)について [#bc592cd4]
-他のプロダクトと同様に、最前線の開発ブランチでは積極的に改変を加え、落ち着いたころにリリースするというサイクルを繰り返します。
++リリースの直後には大規模な変更が増え、逆にリリース前には安定化とバランス調整の作業がが増えます。
++実験的なコードに不都合があればリリースまでに破棄するものもあるでしょう。
++ 最適解を求めて右往左往することもあるでしょう。
++コードを強引にクリンナップすることもあるでしょう。
-それが未来を現実をにするというのが、このブランチの役目です。
--ユーザーデータに関する互換性は基本的に守られますが、コードの中身やファイル構成などの無駄は大幅に整理されることがあります。
***メンテナンスブランチについて [#c4817fd3]
-長期安定運用を現実にするのがこのブランチの役目です。
--ユーザーデータに関する互換性は必ずと言っていいほど守られます。
--コードの中身やファイル構成などの無駄は整理されることがあります。
--また、次の世代へ移行する手順は基本的に変化しません。
-セキュリティ関係のバグフィックス以外は(原則として)行なわない。機能拡張はもちろんのこと、通常のバグについてはサポートしない。
----
**安定版・開発版、CVS版について [#x2e1ebdd]
:安定版|ユーザーに公開することを意識してリリースしたものは安定版
:開発版|開発ブランチの開発途中のもの
:[[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メンテナンスブランチ)
※安定版と呼べる状態は、それぞれほんの一瞬のみ
----
**バージョン [#p521e5f6]
***バージョンアップの定義 [#q0f022b7]
:メジャーバージョン|非互換性が含まれていることを暗示させるために行います。
:マイナーバージョン|(上位あるいは同等の)互換性が保たれていることを暗示させるために行います。
***バージョン定義 [#mb0d7b75]
※バージョン定義については、以下の様な認識であり、意見合わせが出来ていません。
[[ロードマップ/過去の話題]]より
(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};
***その他バージョン定義 [#pdd57c19]
-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
--コードまたはファイル削除を必用とする深刻な問題に対処しリリースしたもの
***バージョン番号の繰り上がりについて [#na06575c]
PukiWikiプロジェクトは、マイナーバージョンの繰り上がり(=リリース頻度)が、メジャーバージョンに影響を与えるという事はありません。~
仮に 1.4.9 の次があるとしたら、1.4.10 のようになります。
時として、マイナーバージョンの桁上がりを一つの区切りとみなしてメジャーバージョンが更新される事はありますが、メジャーバージョンの意味合いを明確にする事による恩恵を受けているプロジェクトでは、脈絡のないメジャーバージョンの更新はデメリットの方が多くなるでしょう。こうした表現は Linux 0.99.10（最初のバージョンは Linux(freax) 0.01 であるため、0.10は今回の例には当てはまらない。1.0のリリースまでに10回以上99回までの更新が意図されていたようだが、結果としては[[0.99まで行った後>http://ftp.cdut.edu.cn/pub2/linux/kernel/history/1991-2.html]]、[[1年以上粘って1.0になった>http://ftp.cdut.edu.cn/pub2/linux/kernel/history/1994.html]]。この例でも、メジャーバージョンはとても意識されている）、FreeBSD 4.10、(OpenSSHが生まれる前の)ssh, glib, OpenLDAP、その他特定の製品をターゲットにした10回目のパッチ・・・等々、以前から行われています。
* コメント [#j3e542cb]
- お疲れ様です。この手の概念には先例があります。 -- [[henoheno]] &new{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
#comment
![[PukiWiki]](image/pukiwiki-dev.png "[PukiWiki]")
