AIDA Shinra
aida-****@jcom*****
2002年 10月 31日 (木) 20:49:33 JST
相田です。 > Canna ぐらいの規模で commit 係を決めても繁雑になるだけだと思います。 > > せっかく cvs を使っているので、 > - 大きな変更は聞いてから commit する。 > - たいした変更ではない(と、ある committer が判断した)場合には、 > 勝手に commit 。 > - 問題があったら協議により戻す。 > というのがきっと楽です。 > > メールに関しては、(大きな変更時に)コンセンサスを取るための > commit 前のメールと、あまりに込み入った変更の場合に(慣れた日本語で) > 説明するための commit 後のメールは必要な場合もありますが、 > commit 時のメールは、せっかく cvs メーリングリストがあるのだから、 > commit mail をちゃんと書く、で十分でしょう。 大御所の御墨付きをもらった&既にcommitが行われているので、今後の開発は 「勝手にcommit」方式でいきます。 > ブランチをどの程度の頻度で切るか、というのもお里によって違って、 > BSD 方面だと「最低限しか切らない FreeBSD」と、 > 「個人が実験用にバンバン切っていい NetBSD」という違いがあります。 > この辺は完全に好みですね。 > > まあ、どれをお使いになっても、似たようなもんですが。 泥縄ですが、誰かが「ブランチが欲しい」と言った時点で決めることにします。 まあ、今後committerが増えてもせいぜいなので、何をやっても大丈夫でしょ う。 > patch release が大量になされる可能性があるのならば、 > patch version を 0 ではなく 00 とか 000 とかから始めるべきで、 > そうなると、3.6.01 はいかにも不格好なので、 > 3.6p01 とかかな、という気がします。 よく分かりませんが、p9からp10に飛ぶと何かまずい問題が起こる、というこ とでしょうか？そんなにpatch releaseを出してどうするのか、という問題は ありますが。 > # 同様に 3.9 の次をどうするか問題などが発生しますが。 これは3.10にするつもりです。取り敢えず3.999までは大丈夫です。 > 今後ずっと現在の ABI に対する後方バイナリ互換を > 保証するということになると思います。 > > あまり Canna の API を見ていないので私には判断できない、 > という意味で純粋に質問なのですが、今の ABI を残したまま > 続けていけるという算段はありますか? ABIにこだわるなら、jrKanjiControl(id, KC_xx, arg)なので、頑張れば何と でもなると思います。極端な話、セマンティクス上どうしても互換を取れなけ れば、KC_SETVERSIONという手もあります。ただ、libcなどと違って、再コン パイルの負担はそれほど大きくありませんし、wc*系関数をどうするか、とい う問題もあるので、さっさと2に上げてしまうかもしれません。 > あと、Canna との通信プロトコルの互換性についても、 > ここで一緒に考えておくべきなのかな、と思います。 これも、プロトコルのバージョンを伝える仕組みはあるので、どうにかなると 思います。 > P.S. > そういえば、もともとの RCS ID が上書きされちゃってますけど、 > これはそういうポリシにしたという理解で正しいですか? 単に面倒だったからそのまま突っ込んだ、というのもありますが、同じCanna という名前で出しているので、特に元のRCS IDを残す必然性は無いと思いまし た。 で、早速ですが、ざっくり安定ブランチを切ろうと思います。HEADは4.0とし て、安定ブランチは取り敢えず3.6のままにします。ブランチ名はRELBR_3とし ます。異論が無ければ週末に切ります。 ---------- AIDA Shinra
