[#30220] schedule for Ruby 1.8.6 — "Akinori MUSHA" <knu@...>

 ruby-core を読んでいない人もいると思うので、ここでもアナウンス

20 messages 2007/01/30

[ruby-dev:30098] Re: version.h maintenance

From: Urabe Shyouhei <shyouhei@...>
Date: 2007-01-06 15:43:09 UTC
List: ruby-dev #30098
卜部です。

SASADA Koichi wrote:
> a) version.h の更新のたびに リビジョン番号が上がるのは好ましくないかも
> b) 変更があった場合、そのリビジョンでは version.h の日付は以前に
> version.h の更新があったときのものになる
>   

a)のほうは「気にするべきではない」と思います。リビジョン番号なんてじゃん
じゃん増えて困るもんじゃないと思います。b)はたしかに問題なような気がしま
すね。

> 1. version.h をコミッタが変更してからコミットする
>
>  これは、version.h を変更してからコミットするようにコミッタに負担を強い
> る方法です。ただ、コミッタの環境でコマンド一発で version.h を更新できる
> ようなツールを作るのは難しくないとは思います。
>
>  コミット時、サーバ側で version.h の変更が無ければコミットさせないよう
> にフィルタを作ることも可能だそうです。
>   

これ(version.hの変更がなければ拒否)は困りませんか?たとえば一日に二回コ
ミットするときとかに。

> 2. version.h はチェックアウトしてから作る
>
>  日付は ChangeLog の行頭などに $Date$ などを加えておくことで、それを解
> 析してから version.h を作成するルールを make に加えることが可能です
> (YARV では revision をそうやって作っていた)。ただし、Subversion ではな
> く、他のツールを使って管理していたりすると、ちょっと変になりそうです。
>
>  tar ボールを作るときには、version.h を作っておいてから、ということにな
> ります。
>   

tarを作るのも自動化するのがいいかもしれませんね。

> 3. version.h から日付情報を消す
>
>  いっそ、日付やめてリビジョン番号だけの表記にするとか(現実的じゃない
> か)。開発者の場合はそれだけでもいいかも。
>   

trunkがそうなるのは構わないと思いますが、互換性がなくなってぎゃっという
人は多そうな気がします...

> 4. 今までどおり後からコミット
>
>  従来どおり、コミットがあってから version.h を更新。1 とあわせ技にする
> のはありなのかも。
>
>
>  3つあげてみたんですが、他にもあると思いますので、何かありましたらご指
> 摘下さい。
>   

結局post-commitでひっかけてversion.hを自動更新するというのは技術的に困難
だったっていう結論なんでしょうか。だとするとありそうな選択肢としてはcron
で毎日一回version.h更新スクリプトを走らせるようにするとか...

In This Thread