1.4は、今でも開発ブランチなのか？†
- ページ: BugTrack2
- 投稿者: upk
- 優先順位: 普通
- 状態: 完了
- カテゴリー: その他
- 投稿日: 2005-02-22 (火) 01:40:36
- バージョン: 1.4
メッセージ†
- 1.4という開発ブランチは、1.4.5までの改定がなされても、今もって開発版のままなのか？
- 1.3を今後とも、安定版として継続保守していくのか？
今一度、この関係を整理しておきたいと考え、ここに計上しました。みなさんのご意見をお願いします。
(以下はBugTrack/709より移動、一部コピー)
- ロジックの根本対応せずとも、md5 対応程度はコミットしておいても良いのでは？ -- upk
- お疲れ様です。とり急ぎ明日 1.4.5_1 をリリースする予定なので、それ以後になりますです -- henoheno
- もはや1.3と1.4の関係は、1.4.5では無いということですかね。では、この状況をどう料理しておきましょうかね？ -- upk
- こんにちは。「1.3と1.4の関係」という部分をもう少し説明してください (^^; それとこのトピックを取り上げるにあたり、何か背景となる話題をすっ飛ばしていませんか? -- henoheno
- 1.4をリリースした際に、1.3の新機能を利用する必要が無い方は、1.4への移行を薦めるるものではない。というアナウンスをしていたと思います。となると1.3が主軸であるということを覆さない限りは、1.4はあくまでも新機能がある版であり、1.4.5はその改定版とだと認識しています。ということで、1.4.5_1 を出そうがそれは、主軸ではない新機能版の改定であって、安定版は、1.3であるという認識でしたので、コミットくらいできますよね？という理解でいました。これが、そうではないというニュアンスで読めましたので、であれば、どうなっているんでしょうかね？ということなんですよね。今でも1.3を継続利用しているサイトが多い理由は、このアナウンスがあったからなんだと認識していますし、henohenoさんが1.3のためのメンテナになったのも、こういう理由があり、継続保守の必要性があったからだと理解していました。それって違うんですかね？ あと、1.3の取り扱いについて、どこかでアナウンスしていたのを見落としていたんでしょうかね？ 何か誤解があれば、教えて下さい。-- upk
- なんでこんなことを言っているのかというと、実は、1.4がリリースされた頃、このサイトを1.4にしたかったんですが、新機能が必要でなければ、1.3からの移行は薦めるものでもない。ということで、1.4にする意味を理解してもらないままに、今でも1.3を継続利用しているんですよねぇ。-- upk
- どの開発ブランチだろうと、リリース前には安定化を図ってからリリースしようとします。これは普通のことですよね。一方で、とりあえずコミットしておいて、そのリビジョンにCVSのタグが打たれないように回避して*1取り扱うことも不可能ではありませんが、現状のリリース工程の中では至極面倒です。余計な手作業をしたばっかりにケアレスミスが発生するようなリスクを負うのもうまくありません。 -- henoheno
- また、この内容は、妥当な意図だと思うのですが、内容としては従来の利用者の移行の手間を増やすものですよね (^^; 今日1.4.5_1リリースがやっと一段落したのがおわかりのように、数日前の状況でこの変更にともなう状況説明をあちこちに加える事まで行うようではリリース作業が止まってしまいます。 -- henoheno
- ということで、今回の話は1.3.x の話と全く関係がありません :) -- henoheno
- 1.4.5_1 に組み込めを言っているわけではなく、1.3と1.4の関係を整理しないと、1.4の動きが遅いままだと考えています(開発ブランチなのに、安定版みたいな重みってありませんか？)。また、1.3の継続保守は、開発者にとって負担にはなりませんか？ということを過去にも指摘はしていますが、1.4.5というリリースもあって整理するタイミングかなと考えています。ということで、BugTrack2/12に計上しました。-- upk
- 言葉の定義の話と、PukiWikiプロジェクトのリリースサイクルの話になってしまいますよ (^^; 農閑期と農繁期があって、リリースの前後は農閑期になります。今は 1.4.5 が難産で 1.4.5_1 を出したくらいですので、よけいにコミットは細く、慎重になります。それだけですよ。 -- henoheno
- 特に今は「収穫お疲れさん」の直後で、店先に新米が並んでいたりするのを出先で眺めつつ、トラクターの買い替えとか、害虫駆除の傾向と対策とか、どこに何を植えるかについて再検討しているような時期かもしれません。 -- henoheno
- というのは 1.4.x の話。1.3.x の畑は人手が足りませんね (^^; 1.4.x の畑に手間がかかりすぎるのは認識していて、あちこち省力化を進めているものの、まだまだ手が足りません。新しく参加していただいた方にも1.4.xを手伝っていただきたいので、1.3.xには回せません。このままでは畑を潰さねばならないでしょう。どこかからIターン就職がないものでしょうか :) -- henoheno
- 1.4.x が開発ブランチかという質問はYesです。一方で定期的にリリースすることを課しているのはプロダクトの健全性を維持するための重要な手法なので、今後も継続します。畑は定期的に耕さないといけません。 -- henoheno
安定版 (Stable release) という言葉について†
- ふと気付いたのですが、official:FrontPageには「安定版の最新バージョンは PukiWiki 1.4.5_1 です。」となっていますね。あれ？(^^; -- sagen
- こんばんは。開発ブランチの開発途中のものは開発版、ユーザーに公開することを意識してリリースしたものは安定版と呼び分けられています。なお、「開発ブランチから任意のタイミングで取り出したもの」はPukiWikiの場合CVS版と言われています。PukiWikiに限らず、一本の開発ブランチで作業しているプロジェクトは全て(より)不安定な状態と(より)安定な状態を行き来します。 -- henoheno
|----------------------- CVS版 (1.4.x開発ブランチ) -------------------->|
======開発版=====> 安定版(1.4.5) =====開発版=====> 安定版(1.4.5_1) ====>
※安定版と呼べる状態は、それぞれほんの一瞬のみ
- 一般ユーザーの視点で言うと、リリースとリリースの合間は、何かしら不安定な状態になります。わかりやすい説明はありません(開発日記とソースを読み解く以外には)。破壊的な修正が加わる可能性もあります。手戻りも起こります。 == 安定じゃない == 不安定版 <==> 安定版... -- henoheno
|----------------------- CVS版 (1.4.x開発ブランチ) -------------------->|
====開発版(1.4.5_alpha)====> 安定版(1.4.5) ====開発版(1.4.6_alpha)===>
|===========> 安定版(1.4.5_1) =========>
分岐 (1.4.5メンテナンスブランチ)
※安定版と呼べる状態は、それぞれほんの一瞬のみ
- 仮に安定版のリリース毎に、個々の安定版をメンテナンスするためのブランチ(専用のソースツリー)を用意する場合、上記のようにソースが分岐します。1.4.5のためのメンテナンス専用ブランチは、メンテナンスだけの最低限の作業だけを行う様にする様にします。 -- henoheno
- このような運営を行っている時でも、CVSで管理しているソースの任意の一瞬を取り出したものは全て不安定版です。メンテナンスのためのブランチが stable ブランチと呼ばれることはありますが、そのブランチにあるものが全て安定だということまでは保証できません。安定版と呼べるのは実際にリリース作業を通して発表されたものだけです。 -- henoheno
- ということで、ちょっと脱線しましたが、「最新の安定版」が1.4.5_1だという表現は妥当であり、1.4.xが「開発ブランチ」であるという表現とは矛盾していないと考えています。これも言葉の定義とリリースサイクルの話です :) -- henoheno
- なるほど……。あ、定義に関する新たな疑問が。:) では、1.4.xが「開発ブランチ」なのに対して、1.3.xは何ブランチと呼ぶんですか？ 「安定ブランチ」とか？ -- sagen
- メンテナンスブランチ?(バグや脆弱性があったら修正する程度) -- ELF
- 1.4ベースは1.4.4辺りから急激に仕様が変わっているので，本当は1.5としてリリースされて欲しかったところではあります． -- ELF
- 「最新の安定版」という表現が1.4.xに対する言葉としてorgのトップページで使われていても、「1.3.xを開発するブランチ」という意味で「1.3.x開発ブランチ」と呼ぶ方がいても、役割からメンテナンスブランチと呼ぶ方がいても、それぞれは「どのような切り口から同じモノを見たか」という話題にすぎないので、私は疑問に思いません。 -- henoheno
- XOOPSの偉い人でも躊躇しますかそうですか。一般人はもっと必死ですね。外人バージョンになっているし。 --
- 流れ的に自意識過剰でなければ私のような気がしますが*3，PukiWikiの設置数が2桁位(半分くらい何らかの改変をしている)あるので大掛かりな修正が続くと追従が大変というだけです．機能修正の方向性(i18nの意識など)は間違ってるとは思いません*4． -- ELF
- ELFさんの言われているのは過去に例えばみこさんも言われていました。「PukiWikiを改造して利用しているユーザーのために、バージョンごとのマイグレーション情報を充実させてはどうか」というのがELFさん(ほかの皆さん)の本当のニーズであるように思うのですが、いかがでしょうか。 -- henoheno
- なんか見てしまったので (^^; コメントしておきます。わたしはそもそもマイグレーション情報が必要になるものはメジャーバージョンorマイナーバージョン（この場合x or y）を上げるべきという発想です。それをおこなわないと多くのオープンソースで行われているルールと違うのでユーザーに混乱をきたすのは自明の理ですから。ELFさんがとられた行動は普通に使用している人だと（世間一般として）あたりまえのようにおもえます。 -- みこ
- ELF的な感覚を下記にまず挙げておきます
| 用語 | 一般的内容 | 開発者向け内容 | 変更すべきバージョン番号の位置 |
| アップデート | ささいなバグ修正，脆弱性の修正．設定ファイルに項目が増えたり意味合いが増えたりは基本的にしない*5．利用者はupgrade～.tar.gzのようなものが提供される場合，運用中のシステムがシステム的な無改造がなければアーカイブの展開されたものを上書きするだけで修正の恩恵を受けることができる．既存ユーザーはマイグレーション情報(henohenoさん定義．以下同様)を読むことは必須ではない | 可能な限りマイグレーション情報を確認すること | x.y.z |
| アップグレード | 比較的大きななんらかの修正．設定ファイルの修正がある場合がある．and/or マイグレーション情報を読まなければ正常なアップグレード作業が行えない可能性がある． | かならずマイグレーション情報を確認すること | x.y.z もしくは x.y.z |
例えば今のPukiWikiのupdateのtarballはそのままコピーするとiniファイルも上書きしてしまい，アップグレードパッケージとしてはかなり危険なものだと思っています．
メジャー・マイナーを付加する場合，個人的にはアップデートにはメジャーもマイナーもない(既存ユーザーは理由がないかぎり利用すべき)，アップグレードは任意という視点でアップデートにはメジャー・マイナーは存在しない，アップグレードには存在してもよい，位の意味合いを持っています．
また，上記考えなので，3桁目(x.y.z)はどんどんあがってよい．また，3桁目の変化に限っては利用者は原則何も考えずにガンガン適用してもよい．そして4桁目(例えば1.4.5_1)はまったく必要ない．-- ELF
- たくさんのPukiWikiユーザーにわかりやすく伝わる表記が大切ではないでしょうか。理屈こねまわすんではなく。最近そうゆう視点が激しく欠けているように思います。仕様とかアナウンスとか。 --
- そうですね。特にPukiWikiをカスタマイズしてお使いになっているユーザーのケアがもう少し要るでしょうか(仕様と言われるのはそういう意味ですよね)。アナウンスと言うのは以前のPukiWikiと比較されているわけではない様ですね。具体的に実際のアナウンスを挙げていただいて、書き直していただけると話が早いかもしれません。お願いできますか。 -- henoheno
- PukiWiki 1.4ベースで言うとpukiwiki-announceのリリースノートは1.4=>1.4.3=>1.4.5*6と歯抜けなので必ずしも今までより情報量が少ないわけじゃないと思います．1.4.5は変更点も要約的にはしっかり書かれてるし． -- ELF
- UPDATING.txtに1.4.5の情報がないですね．1.4.4=>1.4.5と1.4.5=>1.4.5_1の情報が抜けている*7 -- ELF
- 関連：BugTrack2/228 --
- 関連：開発談義/8 --
- 主題に対しての回答が出ていましたんで完了にしました。 --
![[PukiWiki]](image/pukiwiki-dev.png "[PukiWiki]")
