[[:CategoryDev]]

#contents
#ls2

*ロードマップ [#v166c35f]
CENTER:&size(20){(新しいロードマップを検討中)};

**新しいロードマップ作成のための検討 [#n249dcd7]
-1.3時代に書かれたロードマップは現状に合わなくなってきたので、1.4がリリースされたら新たなロードマップを考えないといけないですね。-- [[reimy]] SIZE(10){2003-04-05 (土) 01:33:06}

** リリースとバージョンと (BugTrack/579より移動) [#n869dd20]
-やっぱりそう思いますか? (^^; [[みこ]]さんからもクレームが来ている様に、激しすぎる修正も何だなぁと思って、しばらく修正は控えようと思っていたのですが (^^; -- [[henoheno]] &new{2004-10-18 (月) 21:14:14};
--勘違いされていそうなので (^^; cvsはファイルの移動には弱いので、評価してほしいわけではないものは今回のPHP5のようにブランチしてほしいんですけど・・・また、大きくファイル構成が変わったときは、リリース時のバージョン番号は小数点1位の番号を変えてほしいともおもっています。(1.4.3->1.4.4のときもかなり不安がありましたし、 これだけ修正されていたら、次回のリリース時には 1.5を名乗っても不思議はないかと思います。) -- [[みこ]] &new{2004-10-20 (水) 13:58:45};
--ちなみに、PHP5対応はもう1.4.5を名乗ってもいいのではないかとすらおもっています。 -- [[みこ]] &new{2004-10-20 (水) 14:13:20};
--バージョンの定義を定める前にロードマップを作り直さないといけないような気がします。 (^^; 1.5で追加すべき機能とそうでない機能をきちんと区別するべきであると思います。 -- [[Ratbeta]] &new{2004-10-20 (水) 18:23:26};

-まず、CVSでファイルの移動を記録できなかったり、後からそれを知ることができないというわけではありません(ViewCVSやChangeLogやコミットログをチェックできます)。また、ファイルの中身の移動(関数定義をファイルからファイルへ移動する等)が記録できない点についてはどのソース管理製品でも似たり寄ったりです。例えばSubversionであればこれらの状況が変わるという話ではありませんよね。そしてこうした状況が、ブランチを切ればカバーできるというわけではありません。結局チェックすべき部分は同じです。このようなことから、CVSに関するご意見には説得力を感じていません。何か誤解されていると思います(小さなことですよネ。この点で何かあるなら話題を分けましょう) -- [[henoheno]] &new{2004-10-24 (日) 15:33:19};

-[[みこ]]さんが触れられている/期待されているのはメンテナンス(含む評価)のためのブランチを作るという手法と、それが欲しいというご要望の様ですね。細かく評価していただいている様で大変ありがたいのですが、開発ブランチ(trunk)に対して高頻度にそれをするとお疲れになってしまうことでしょうから、お気持ちはわかります (^^; ((苦労のほどは http://pukiwiki.cafelounge.net/plus/ の開発日記を読むべし)) -- [[henoheno]] &new{2004-10-24 (日) 15:33:32};

-現状のPukiWikiのCVSリポジトリの実態は、「1.3のための(ほとんど死んでいる)メンテナンスブランチ」と、「1.4.xの開発ブランチ(trunk)」です。開発ブランチが本当の意味で安定するのは、リリースされる度のわずかな一瞬でしかありません。1.3ブランチが停滞しているの直接の原因は、1.4ブランチに未解決の問題がとても多く含まれているからです。 -- [[henoheno]] &new{2004-10-24 (日) 15:34:31};

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

-''「メンテナンスブランチ」''に対する認識はこうです。長期安定運用を現実にするのがこのブランチの役目です。ユーザーデータに関する互換性は必ずと言っていいほど守られます。コードの中身やファイル構成などの無駄は整理されることがあります。また、次の世代へ移行する手順は基本的に変化しません。 -- [[henoheno]] &new{2004-10-24 (日) 15:34:55};

-「メジャー」「マイナー」バージョンに対する認識はこうです。メジャーバージョンの変化は、非互換性が含まれていることを暗示させるために行います。マイナーバージョンの変化には、(上位あるいは同等の)互換性が保たれていることを暗示させるために行います。(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};
-(といった事を何日か前にローカルに書いていました) -- [[henoheno]] &new{2004-10-24 (日) 15:36:35};

-1.4.4_php5 (PHP5対応 特別版)を出すにあたって、1.4.4.1 といったリリースバージョンをつける事も考えたのですが、1.4.4_php5 の実体がphp5ブランチにあるという事と、今回の目的はあくまでも可及的に速やかにPHP5対応を施したPukiWikiを世に出すことでしたから、その目的とおりの(特別なものとして)出し方をさせていただきました。 -- [[henoheno]] &new{2004-10-24 (日) 15:40:52};

-1.4.4_php5 を 1.4.5 という名前で「次期バージョン」として出すつもりは全くありませんでした。正式なリリースとして広く利用を呼びかけるようなものであれば、利用者にシステムの入れ替えを行わせられるほどの説得力を持った、万人向けの改善がそれなりに必要であると考えています。であればこそ、リリースのためにテストをしたり、ドキュメントをまとめたりするリリースエンジニアリング作業の労苦と釣り合います -- [[henoheno]] &new{2004-10-24 (日) 15:42:33};
-出さない理由もう一つ。正式なリリースを出す期間の問題です。長すぎるのも短すぎるのも良くありません。PukiWikiというプロダクトとその利用者について言えば、数ヶ月(三ヶ月以上)に一回あたりが適当と考えます。六ヶ月は長すぎだし一ヶ月は短すぎです。数ヶ月に一回程度であれば、管理者の方がPukiWikiの入れ替えに関心を持つ機会としても、我々がリリースについて考える頻度(負担)としても折り合いが付くと考えています。 -- [[henoheno]] &new{2004-10-24 (日) 15:48:46};
--そのくらいが妥当だと思います。 -- [[merlin]] &new{2004-10-24 (日) 19:09:18};
--問題は正式なリリースの定義と役割かと思っています。 linux-kernel の pre に当たるのは、daily-CVS が受け持つとしても 脆弱性や問題点を解決したものをその場で手に入れられる手法が必要かと思います。アップデートの容易さの提供が必要ですけど (CVS使える場合は問題ないですけどね) -- [[merlin]] &new{2004-10-24 (日) 19:24:23};
--アップデータのベースにするなら[[org:自作プラグイン/cvscheck.inc.php]]あたりでしょうか…? -- [[Ratbeta]] &new{2004-10-24 (日) 21:21:04};
---cvscheck.in.php を、一次情報を得るためのメンテナンスツールとして紹介するのは良くありません。問題点については、[[BugTrack/659]] をチェックして下さい -- [[henoheno]] &new{2004-10-24 (日) 22:38:20};
--インストール-1.4.4 のページからすぐわかる様に、エラータのページを作るのはどうかと思っています。バージョンごとにどんなナニがみつかってどうなった、あるいはこうしてね、という情報と詳細へのリンクをまとめます。 -- [[henoheno]] &new{2004-10-24 (日) 22:34:25};


#comment

----------------------------------
-バージョンアップの定義について、色々出てきたので論点を少しまとめましょう。 -- anonyumous
--バージョンアップの種類について
---php5対応もマイナーバージョンアップと考えて良いのでは([[みこ]])
---メジャー/マイナーがある。php5対応は本当に特例。内容的にはマイナーバージョンを上げるに値するほどのものではなく、あくまでも1.4.4。 (henoheno)
--バージョン番号(Ver x.y.z)とバージョンアップの関係
--改善の単位とバージョンアップの関係
---利用者の入れ替え、リリース担当のリリースエンジニアリング作業の労苦と釣り合う万人向けの改善が必要(henoheno)
---ファイル構成が変わったら小数点1位を上げたほうが良いのでは([[みこ]])
--リリース間隔とバージョンアップの関係
---正式なバージョンアップの間隔は数ヶ月(三ヶ月以上)に一回あたりが適当(henoheno)



** PukiWiki ロードマップ ([[merlin]]案) [#va5d738c]

*** Version の定義 [#n9ceca31]
- #.#.* : Bugfix を中心とした Version-Up
- #.*.# : 構造変更、機能変更 などを伴う Version-Up 上位互換性確保
- *.#.# : 大規模な 構造変更、機能変更 などを伴う Version-Up 互換性問わず
*** 1.4.4 [#a58319ff]
+ スケーラビリティの向上
+ 初期化処理の見直し
+ PukiWikiを容易に三分割できる様に修正
+ 携帯電話およびPDAなどからのアクセスに対応
+ セキュリティの向上: XSS脆弱性の修正
*** 1.5 [#qbd7233b]
+ 多言語化への対応の強化
+ スキンまわりの整理および改善
+ プラグイン仕様のシェープアップ
+ インストールの容易化
+ RSS/RDF 関連強化
+ 掲示版/Weblog関連機能の整理/強化
+ PHP/5 正式対応
*** 1.6 [#k03e453f]
+ ユーザー認証(メンバー認証)の強化
+ Webからの設定インターフェース
+ ユーザビリティ/人間工学に基づいた WebDesignの指向 
+ WikiFarm 機能の実装
+ プログラムアップデート機構の搭載
*** 1.7 [#va52b844]
+ クラス化の強化

*** 2.0 [#z9f38e5d]
+ SQL-DB対応
+ スケーラビリティ強化

#hr
-とりあえず書いてみました。 叩いてください  -- [[merlin]] &new{2004-10-24 (日) 10:42:14};
-うーん、すぐ上の[[みこ]]さんのものと同じ様に、この案は[[merlin]]さん案として読ませていただこうかと思います。プロダクトバージョンや、実現に至る過程に関する各メンバーの考え方が異なっている、というのが以前からの問題の様ですので。 -- [[henoheno]] &new{2004-10-24 (日) 15:22:43};
-そのためには、各メンバーの考えを聞きたいのです。PHP5正式対応、というのがどう正式であるのかと、以前[[Board/discussion]]で示されていた "Full multilingual features" の概略も教えて下さい。  -- [[henoheno]] &new{2004-10-24 (日) 15:27:04};
--とりあえず書いていかないと進まないので... あと、項目の実現時期は、適当にいれてます (^^; &br; PHP5正式対応というのは、現在のCVSでは実質 PHP4 PHP5に対応しているので、PHP4,5対応のパッケージを出すということです。&br; 多国語機能完全対応は、多国語のドキュメントやコンテンツメッセージなどは navtive の力を借りないとだめなのですが、それらを容易に取り込める環境を作るというのをイメージしています。-- [[merlin]] &new{2004-10-24 (日) 15:53:54};
-ふむふむ。気楽なのが一番でーす :) PHP4,5対応のパッケージというのは「正式リリース」といった意味合いでしょうか、それでしたら、次のリリース1.4.5では確実にそう(両対応)なりますから、1.4.5あるいは1.4.x という項目を作ってそちらに移すのはいかがでしょう -- [[henoheno]] &new{2004-10-24 (日) 16:21:33};
--次が 1.5だと 思って書いていました (^^;  -- [[merlin]] &new{2004-10-24 (日) 16:29:55};
-なるほど (^^; 私が 1.4.x シリーズしか出すつもりが無いのがバレましたね(ぉ -- [[henoheno]] &new{2004-10-24 (日) 16:37:23};

-バージョンは三桁の下にもう一つ桁を設けるべきでは?緊急のバグや脆弱性が存在した場合に1.x.x.1とかするのはどうでしょう? -- [[Ratbeta]] &new{2004-10-24 (日) 16:56:47};
--henoheno氏のイメージだとそれも良いかもしれませんね。  -- [[merlin]] &new{2004-10-24 (日) 19:05:59};
--しかしながら、私のイメージでは それを3桁目が受け持つ感じなんですが -- [[merlin]] &new{2004-10-24 (日) 19:07:41};
---で、M$の法則が示す通りだとX,X,3ぐらいから安定してくる また linux-kernelのようだと X.X.15ぐらいからかな と :D -- [[merlin]] &new{2004-10-24 (日) 19:10:06};
--1.4.3から1.4.4の変更を見ていると、三桁目でそれを行うのは無理が有る気がします。 -- [[Ratbeta]] &new{2004-10-24 (日) 21:28:18};
--1.4.x については、未整理の部分を整理するだけで新しい機能が生まれてしまうくらいの要素(未解決の問題や未調整のバランス)が沢山あります。なので変更の規模が毎度大きいのです (^^; そしてその効果も大きいのです。負担も大きいのでorz -- [[henoheno]] &new{2004-10-24 (日) 22:32:03};

-オープンソース開発でよくやられているように 偶数 stable 奇数 unstable なのも良いかと思ってます。つまり 次は 1.6  -- [[merlin]] &new{2004-10-24 (日) 19:13:52};
--それだとunstableの次は必ずstableにしなければなりませんよ…?一度順番が狂うと修正が効きにくいですし。 (^^; -- [[Ratbeta]] &new{2004-10-24 (日) 21:04:58};
--うーんと、他のプロジェクトのリリースエンジニアリングの手法(リリースバージョンの付け方、CVSブランチの切り方などを含む)を参考にするのはとても良いことなのですが、ここの目標は今ここにあるPukiWikiという小さなプロダクトの現状をふまえた対策です。現時点でもアレですが、ブランチを複数同時進行で抱えるのは労力的にとても大変だと思ってください (^^; PHP5対応の時にやった様に、ブランチコントロール自体は何の問題もないのですけれどね。((FreeBSDのCVSブランチの切り方も興味深いですよ)) -- [[henoheno]] &new{2004-10-24 (日) 22:45:32};

#comment


** ロードマップ ([[henoheno]]案) [#vbcb761a]
-折角なので、私の案も書いておこうかな :) -- [[henoheno]] &new{2004-10-24 (日) 16:23:02};

*** 1.4.5 [#vbb9ef6d]
+ さらなるクリンナップ
-- コードの可読性向上と無駄な処理の削減、スタイルの統一
-- 冗長なファイル構成の整理と削減
--- スキン
--- CSS
--- 国際化: UI部分(のみ)の英語化を可能に
+ リモートバックアップ機能 (dumpプラグイン)
-- ※リモートリストアは制限あり、小規模サイト向け。デフォルトで無効
+ 閲覧・編集前の事前認証を可能に/マルチユーザー

*** 1.4.x [#v1400dfb]
+ 今までに上がった将来像のうち、実現可能なもの全て
-- PEAR::DB
-- SiteDev のような read only 用途に対する明確な回答 (拒否しない)
+ 今までに上がった将来像を実現させるために、未検討あるいは未解決のもの全て

*** PukiWiki 2 [#nd2286d7]

「どうのつるぎ」から((「聖なるナイフ」や「鉄の斧」を飛び越して))「はがねのつるぎ」((クリスタルのつるぎへは? by merlin))へ

+ PHP5のみに対応
-- コア部分はごく最小限の手続き処理
-- コア部分を除きクラスライブラリ化 (によるデータの隠蔽)
-- PEAR標準コーディング規約への準拠
+ ミドルウェアから極力独立させる
-- データ処理の抽象化
--- より洗練させた text data ライブラリ
--- RDBMS対応 (PDO)
-- レンダリング/IOエンジンの分離
--- プラグインはミニrenderer/modelerという位置付け
+ 認証モジュール
-- XOOPS由来のアレ
-- LDAP
+ 万単位のページ処理
-- ページ束の操作インターフェース
+ 複数のPukiWikiのミックス (メディア管理、クロスPukiWiki InterWiki)
-- 現在のPukiWikiは data, diff, backup, attach, trackback という五つのメインメディアで構成されたものとみなす (分解する)
-- メディアの選択およびその数、それらのクロスのさせ方を任意にする

-------------------------
-%%全く関係ない話ですが、このページ脚注が変な事になってますよ?%%目の錯覚だったみたいです…orz -- [[Ratbeta]] &new{2004-10-24 (日) 21:22:44};
-ロジック寄りの議論になっているのでちょっと違った視点で2点ほど。 wiki.enの翻訳,初期コンテンツの充実(マニュアル)もPukiWikiの一部って事で忘れないで :) &br;もう一点、国際化対応は相手あっての事なので安定版(メンテナンスブランチ)としてリリースしないと使い始めて貰う(駄目出ししてもらう?)タイミングがいつまでもやってこないのではないでしょうか? -- [[にぶんのに]] &new{2004-10-24 (日) 23:27:51};

#comment

----------------------------
** PukiWiki の 将来像 [#v08f1444]
-こんな感じなのかなぁ -- [[merlin]] &new{2004-10-24 (日) 18:52:36};~
1.3系 : どうしても HTML 4.1対応でないとまずい場合用~
1.4~1.9 : XHTML1.0,XTHML1.1対応 DB未使用前提 PHP4/5 対応~
2.0系 : XHTML Strict系  DB使用前提 PHP5専用大規模使用も想定 CMSとしても構成できる~
の3本柱になるのか? 基本的に上位の方が高機能。

#comment

トップ   新規 一覧 検索 最終更新   ヘルプ   最終更新のRSS
Site admin: PukiWiki Development Team

PukiWiki 1.5.3+ © 2001-2020 PukiWiki Development Team. Powered by PHP 5.6.40-0+deb8u12. HTML convert time: 0.042 sec.

OSDN