過去の話題†
新しいロードマップ作成のための検討†
- やっぱりそう思いますか？ (^^; みこさんからもクレームが来ている様に、激しすぎる修正も何だなぁと思って、しばらく修正は控えようと思っていたのですが (^^; -- henoheno
- 勘違いされていそうなので (^^; cvsはファイルの移動には弱いので、評価してほしいわけではないものは今回のPHP5のようにブランチしてほしいんですけど・・・また、大きくファイル構成が変わったときは、リリース時のバージョン番号は小数点1位の番号を変えてほしいともおもっています。（1.4.3->1.4.4のときもかなり不安がありましたし、 これだけ修正されていたら、次回のリリース時には 1.5を名乗っても不思議はないかと思います。） -- みこ
- ちなみに、PHP5対応はもう1.4.5を名乗ってもいいのではないかとすらおもっています。 -- みこ
- バージョンの定義を定める前にロードマップを作り直さないといけないような気がします。 (^^; 1.5で追加すべき機能とそうでない機能をきちんと区別するべきであると思います。 -- Ratbeta
- まず、CVSでファイルの移動を記録できなかったり、後からそれを知ることができないというわけではありません(ViewCVSやChangeLogやコミットログをチェックできます)。また、ファイルの中身の移動(関数定義をファイルからファイルへ移動する等)が記録できない点についてはどのソース管理製品でも似たり寄ったりです。例えばSubversionであればこれらの状況が変わるという話ではありませんよね。そしてこうした状況が、ブランチを切ればカバーできるというわけではありません。結局チェックすべき部分は同じです。このようなことから、CVSに関するご意見には説得力を感じていません。何か誤解されていると思います(小さなことですよネ。この点で何かあるなら話題を分けましょう) -- henoheno
- みこさんが触れられている／期待されているのはメンテナンス(含む評価)のためのブランチを作るという手法と、それが欲しいというご要望の様ですね。細かく評価していただいている様で大変ありがたいのですが、開発ブランチ(trunk)に対して高頻度にそれをするとお疲れになってしまうことでしょうから、お気持ちはわかります (^^; *1 -- henoheno
- 現状のPukiWikiのCVSリポジトリの実態は、「1.3のための(ほとんど死んでいる)メンテナンスブランチ」と、「1.4.xの開発ブランチ(trunk)」です。開発ブランチが本当の意味で安定するのは、リリースされる度のわずかな一瞬でしかありません。1.3ブランチが停滞しているの直接の原因は、1.4ブランチに未解決の問題がとても多く含まれているからです。 -- henoheno
- 「開発ブランチ(trunk)」に対する認識はこうです。他のプロダクトと同様に、最前線の開発ブランチでは積極的に改変を加え、落ち着いたころにリリースするというサイクルを繰り返します。リリースの直後には大規模な変更が増え、逆にリリース前には安定化とバランス調整の作業がが増えます。実験的なコードに不都合があればリリースまでに破棄するものもあるでしょう。最適解を求めて右往左往することもあるでしょう。コードを強引にクリンナップすることもあるでしょう。それが未来を現実をにするという、このブランチの役目です。ユーザーデータに関する互換性は基本的に守られますが、コードの中身やファイル構成などの無駄は大幅に整理されることがあります。 -- henoheno
- 「メンテナンスブランチ」に対する認識はこうです。長期安定運用を現実にするのがこのブランチの役目です。ユーザーデータに関する互換性は必ずと言っていいほど守られます。コードの中身やファイル構成などの無駄は整理されることがあります。また、次の世代へ移行する手順は基本的に変化しません。 -- henoheno
- 「メジャー」「マイナー」バージョンに対する認識はこうです。メジャーバージョンの変化は、非互換性が含まれていることを暗示させるために行います。マイナーバージョンの変化には、(上位あるいは同等の)互換性が保たれていることを暗示させるために行います。(PukiWiki n.n.n という数字の何がメジャーかどうかというのはさておき、メジャー番号の違いが示唆するのは「徹底的な内部構造の非互換」です) -- henoheno
- さて、何をもって 1.3 や 1.4 や 1.5 や 2.0 であるのか、あるいは何がメジャーバージョンでマイナーバージョンなのか、各人の希望が実情と合っているのかどうか、といった話を含め、開発とメンテナンスとリリースに関する認識について意見交換をした方が良さそうな感じですね :) -- henoheno
- (といった事を何日か前にローカルに書いていました) -- henoheno
- 1.4.4_php5 (PHP5対応 特別版)を出すにあたって、1.4.4.1 といったリリースバージョンをつける事も考えたのですが、1.4.4_php5 の実体がphp5ブランチにあるという事と、今回の目的はあくまでも可及的に速やかにPHP5対応を施したPukiWikiを世に出すことでしたから、その目的とおりの(特別なものとして)出し方をさせていただきました。 -- henoheno
- 1.4.4_php5 を 1.4.5 という名前で「次期バージョン」として出すつもりは全くありませんでした。正式なリリースとして広く利用を呼びかけるようなものであれば、利用者にシステムの入れ替えを行わせられるほどの説得力を持った、万人向けの改善がそれなりに必要であると考えています。であればこそ、リリースのためにテストをしたり、ドキュメントをまとめたりするリリースエンジニアリング作業の労苦と釣り合います -- henoheno
- 出さない理由もう一つ。正式なリリースを出す期間の問題です。長すぎるのも短すぎるのも良くありません。PukiWikiというプロダクトとその利用者について言えば、数ヶ月(三ヶ月以上)に一回あたりが適当と考えます。六ヶ月は長すぎだし一ヶ月は短すぎです。数ヶ月に一回程度であれば、管理者の方がPukiWikiの入れ替えに関心を持つ機会としても、我々がリリースについて考える頻度(負担)としても折り合いが付くと考えています。 -- henoheno
- そのくらいが妥当だと思います。 -- merlin
- 問題は正式なリリースの定義と役割かと思っています。 linux-kernel の pre に当たるのは、daily-CVS が受け持つとしても 脆弱性や問題点を解決したものをその場で手に入れられる手法が必要かと思います。アップデートの容易さの提供が必要ですけど (CVS使える場合は問題ないですけどね) -- merlin
- アップデータのベースにするならofficial:自作プラグイン/cvscheck.inc.phpあたりでしょうか…？ -- Ratbeta
- よくよく考えると、"更新する"ことと"CVSから取得する"ことは少し違いましたね…orz この辺りの仕組みはまた別に考える必要がありそうです…。 -- Ratbeta
- インストール-1.4.4 のページからすぐわかる様に、エラータのページを作るのはどうかと思っています。バージョンごとにどんなナニがみつかってどうなった、あるいはこうしてね、という情報と詳細へのリンクをまとめます。 -- henoheno
まとめ†
- バージョンアップの定義について、色々出てきたので論点を少しまとめましょう。 -- anonyumous
- バージョンアップの種類について
- php5対応もマイナーバージョンアップと考えて良いのでは(みこ)
- メジャー/マイナーがある。php5対応は本当に特例。内容的にはマイナーバージョンを上げるに値するほどのものではなく、あくまでも1.4.4。 (henoheno)
- バージョン番号(Ver x.y.z)とバージョンアップの関係
- 改善の単位とバージョンアップの関係
- 利用者の入れ替え、リリース担当のリリースエンジニアリング作業の労苦と釣り合う万人向けの改善が必要(henoheno)
- ファイル構成が変わったら小数点１位を上げたほうが良いのでは(みこ)
- リリース間隔とバージョンアップの関係
- 正式なバージョンアップの間隔は数ヶ月(三ヶ月以上)に一回あたりが適当(henoheno)
PukiWiki ロードマップ (merlin案)†
Version の定義†
- #.#.* : Bugfix を中心とした Version-Up
- #.*.# : 構造変更、機能変更 などを伴う Version-Up 上位互換性確保
- *.#.# : 大規模な 構造変更、機能変更 などを伴う Version-Up 互換性問わず
1.4.4 (※ここに書かれている事は実際のアップデート内容)†
- スケーラビリティの向上
- 初期化処理の見直し
- PukiWikiを容易に三分割できる様に修正
- 携帯電話およびPDAなどからのアクセスに対応
- セキュリティの向上: XSS脆弱性の修正
1.5†
- 多言語化への対応の強化
スキンまわりの整理および改善 => 1.4.5等で随時実施- プラグイン仕様のシェープアップ
- インストールの容易化
RSS/RDF 関連強化 => feedプラグイン (BugTrack2/45)- 掲示版/Weblog関連機能の整理/強化
PHP/5 正式対応 => PHP4/PHP5 両対応 (PukiWiki 1.4.4_php5, 1.4.5で実現)
1.6†
ユーザー認証(メンバー認証)の強化 => パスワード保存方式のLDAP互換 (1.4.6)- Webからの設定インターフェース
- ユーザビリティ/人間工学に基づいた WebDesignの指向
- WikiFarm 機能の実装
- プログラムアップデート機構の搭載
1.7†
- クラス化の強化
2.0†
- SQL-DB対応
スケーラビリティ強化 => 随時
- とりあえず書いてみました。 叩いてください -- merlin
- うーん、すぐ上のみこさんのものと同じ様に、この案はmerlinさん案として読ませていただこうかと思います。プロダクトバージョンや、実現に至る過程に関する各メンバーの考え方が異なっている、というのが以前からの問題の様ですので。 -- henoheno
- そのためには、各メンバーの考えを聞きたいのです。PHP5正式対応、というのがどう正式であるのかと、以前Board/discussionで示されていた "Full multilingual features" の概略も教えて下さい。 -- henoheno
- とりあえず書いていかないと進まないので... あと、項目の実現時期は、適当にいれてます (^^;
PHP5正式対応というのは、現在のCVSでは実質 PHP4 PHP5に対応しているので、PHP4,5対応のパッケージを出すということです。
多国語機能完全対応は、多国語のドキュメントやコンテンツメッセージなどは navtive の力を借りないとだめなのですが、それらを容易に取り込める環境を作るというのをイメージしています。-- merlin
- ふむふむ。気楽なのが一番でーす :) PHP4,5対応のパッケージというのは「正式リリース」といった意味合いでしょうか、それでしたら、次のリリース1.4.5では確実にそう(両対応)なりますから、1.4.5あるいは1.4.x という項目を作ってそちらに移すのはいかがでしょう -- henoheno
- 次が 1.5だと 思って書いていました (^^; -- merlin
- なるほど (^^; 私が 1.4.x シリーズしか出すつもりが無いのがバレましたね(ぉ -- henoheno
- バージョンは三桁の下にもう一つ桁を設けるべきでは？緊急のバグや脆弱性が存在した場合に1.x.x.1とかするのはどうでしょう？ -- Ratbeta
- henoheno氏のイメージだとそれも良いかもしれませんね。 -- merlin
- しかしながら、私のイメージでは それを３桁目が受け持つ感じなんですが -- merlin
- で、M$の法則が示す通りだとX,X,3ぐらいから安定してくる また linux-kernelのようだと X.X.15ぐらいからかな と :D -- merlin
- 1.4.3から1.4.4の変更を見ていると、三桁目でそれを行うのは無理が有る気がします。 -- Ratbeta
- 1.4.x については、未整理の部分を整理するだけで新しい機能が生まれてしまうくらいの要素(未解決の問題や未調整のバランス)が沢山あります。なので変更の規模が毎度大きいのです (^^; そしてその効果も大きいのです。負担も大きいのでorz -- henoheno
- オープンソース開発でよくやられているように 偶数 stable 奇数 unstable なのも良いかと思ってます。つまり 次は 1.6 -- merlin
- それだとunstableの次は必ずstableにしなければなりませんよ…？一度順番が狂うと修正が効きにくいですし。 (^^; -- Ratbeta
- うーんと、他のプロジェクトのリリースエンジニアリングの手法(リリースバージョンの付け方、CVSブランチの切り方などを含む)を参考にするのはとても良いことなのですが、ここの目標は今ここにあるPukiWikiという小さなプロダクトの現状をふまえた対策です。現時点でもアレですが、ブランチを複数同時進行で抱えるのは労力的にとても大変だと思ってください (^^; PHP5対応の時にやった様に、ブランチコントロール自体は何の問題もないのですけれどね。*2 -- henoheno
- 小さいプロジェクト ですからね。 stable/unstable を作るとそれぞれにメンテナが必要ですし.. unstable は 現在は trunk CVS なわけですが、aptなんか考えると パッケージ化されていたりするのも必要かな？なんて思ったりします。ユーザーが今どのバージョン(とプラグインの組合せ)を使っているかが明確になるような手法も必要だと感じています。 どうやるのがいいのかなぁ？ -- merlin
- 本当は私が 1.3.x のメンテナとして名乗りをあげたのですが、いろいろあって現在は全部見ています。メンテナは足りないですね。 -- henoheno
- rpm, FreeBSD ports、Windowsインストーラなどを作ろうとする時、メンテナンス用のブランチは必要になって来ると思います。逆に言えば、そのような体制が無ければ手は出せないですね(アップデートの度にユーザーにひどい目にあわせてしまいます)。また、公式にそうしたいのならば、英語版のためのリソースが必須ですね。少なくとも国際化の前に英語化が必要です。 -- henoheno
- ああそうだ、パッケージを出そうという場合、過去にも言われてきたことですが、バージョンアップがうまく成功する構造に直す必要があります。/etc/pukiwiki/ に作ったコンフィギュレーションを読んでデフォルト値をオーバーライドするような仕組みですね。でないと、うまくアップデートに成功しません。 -- henoheno
1.4.5†
- さらなるクリンナップ
コードの可読性向上と無駄な処理の削減、スタイルの統一 => 随時冗長なファイル構成の整理と削減 実現
スキンCSS国際化: UI部分(のみ)の英語化を可能に 実現
リモートバックアップ機能 (dumpプラグイン) 搭載
※リモートリストアは制限あり、小規模サイト向け。デフォルトで無効
- 閲覧・編集前の事前認証を可能に／マルチユーザー
1.4.x†
- 今までに上がった将来像のうち、実現可能なもの全て
- PEAR::DB
SiteDev のような read only 用途に対する明確な回答 (拒否しない) => PKWK_READONLY (PukiWiki 1.4.5)
- 今までに上がった将来像を実現させるために、未検討あるいは未解決のもの全て
PukiWiki 2†
「どうのつるぎ」から*3「はがねのつるぎ」*4へ
- PHP5のみに対応
- コア部分はごく最小限の手続き処理
- コア部分を除きクラスライブラリ化 (によるデータの隠蔽)
- PEAR標準コーディング規約への準拠
- ミドルウェアから極力独立させる
- データ処理の抽象化
- より洗練させた text data ライブラリ
- RDBMS対応 (PDO)
- レンダリング/IOエンジンの分離
- プラグインはミニrenderer/modelerという位置付け
- 認証モジュール
- 万単位のページ処理
- 複数のPukiWikiのミックス (メディア管理、クロスPukiWiki InterWiki)
- 現在のPukiWikiは data, diff, backup, attach, trackback という五つのメインメディアで構成されたものとみなす (分解する)
- メディアの選択およびその数、それらのクロスのさせ方を任意にする
全く関係ない話ですが、このページ脚注が変な事になってますよ？目の錯覚だったみたいです…orz -- Ratbeta - ロジック寄りの議論になっているのでちょっと違った視点で２点ほど。 wiki.enの翻訳，初期コンテンツの充実（マニュアル）もPukiWikiの一部って事で忘れないで :)
もう一点、国際化対応は相手あっての事なので安定版（メンテナンスブランチ）としてリリースしないと使い始めて貰う（駄目出ししてもらう？）タイミングがいつまでもやってこないのではないでしょうか？ -- にぶんのに
- コメントありがとうございます :) 国際化対応という件については、既に駄目出しを始めているので問題ありません(キッパリ)。期待したり、話に上がっていることが実装(実現)されていないので、使い始めてもらうべき存在がまだありません。en.lng の中にもコメントで駄目出しがあるのは知っていますが、今はまだ言語リソースの格納方法や置き場所を含めた全体の再構成を手がけており、そこまで至っていません。例えばいにしえのMacintoshはりソースフォークに言語データを収める様にできていましたが、PukiWikiにはまだリソースフォークという概念が実装されていないのです。そんな状態ですね。 -- henoheno
- RDBMSの採用は、そっちの管理も大変なのでナニな感じがしています。現状との中間をとって、BerkeleyDBを使ってみるというのはダメでしょうか? -- よっちい
- こんにちは ;) そういう意味では、KinoWikiはSQLiteを使っていますね。どんなものにせよ取り組んでみれば、本体にフィードバックすべき事項が浮かび上がって来るとおもいますよ。 -- henoheno
- あー、なるほど。SQLiteならPEAR経由で使えるので拡張性(発展性?)が見込めますね。subversionといいgonzuiといい身近にBerkeleyDB使ったやつが増えてきたので、思いつきで言ってしまいました。反省します。 -- よっちい
PukiWiki の 将来像†
- こんな感じなのかなぁ -- merlin
1.3系 ： どうしても HTML 4.1対応でないとまずい場合用
1.4～1.9 : XHTML1.0,XTHML1.1対応 DB未使用前提 PHP4/5 対応
2.0系 : XHTML Strict系 DB使用前提 PHP5専用大規模使用も想定 CMSとしても構成できる
の３本柱になるのか？ 基本的に上位の方が高機能。
- こういってはなんですけど、最近のPukiwikiは、基本的にメンテナンスですか？それ自体は、全然OKなんですけど、henohenoさんが開発始めてから、きっちりとロードマップが示されていないのが非常に気になります。ここにあるのも所詮過去の遺物でしかないですよね。今で言ったら、Pukiwiki1.5ってなに？、2.0って何？？っていうのが、まったくわかりません。 -- まっくず
- うーむ、確かに最近はバグフィクスばかりかなぁ・・・でもそれをしないで機能を追加しても穴だらけになってしまうし・・・ --
- 久しぶりに*6きたら、気になるコメント....メンテナになれない自分がくやしい....「Wikiは参加するより作りたくなる」っていう言葉は有名ですが、星の数ほどあるWikiクローンのなかでPukiWikiがなぜここまで愛されているかを考えてみたいですね。そこに進むべき道があるように思います。そしてこれだけ多くの人に使われているからこそ、メンテンナンスは他を犠牲にしても重要なこと。そのことに尽力してくれてるhenohenoさんをはじめメンテナの方々にはホント感謝してます。PukiWikiらしさ＋Devチームのモチベーションが重なるところへ進んでいっていいんだと思います。 -- tomix
- なにもやってないのに自分の意見だけいちゃいますが、ボクにとってPukiWikiらしさって、気軽にはじめられる*7＋カスタマイズの奥が深い*8です。将来期待するのはcoWikiのようなユーザー管理と権限、WikiFarmの実現かな。長い将来ではオントロジの交換ツールとしての方向とか....*9 ボクにとってWikiはWWW本来の姿を完成させるための存在だと思っています。 -- tomix
- Ajaxを使ったPukiWikiも面白そう･･･ LesserWikiをみての感想 --
Last-modified: 2007-07-09 (月) 00:39:31
![[PukiWiki]](image/pukiwiki-dev.png "[PukiWiki]")
