travis-ci.org に行って、Restart ボタンを押すだけの簡単なお仕事。
それはいいんだけど、Ruby や Rails 界隈では更新のない gem は使わない、使用を控える、同じ機能なら新しい方、開発が活発な方という指針が一部あって(そんな気がする)、せっかく最新バージョンでも動くのにバグフィックスや機能追加がない、つまり更新がないだけで使われない gem も出てくるわけです。
さすがにあまりないだろうけど、更新がないだけで後発の同じ機能を持つ車輪の再発明 gem の方を優先されたら作者としては悔しいわけです。動くのに。
でも「travis-ci.org に行って、Restart ボタンを押すだけの簡単なお仕事」だけだと、Github にも Rubygems.org にも維持してる証拠が残らないんですよね。
gem の選別してる時に、Github で最終更新日や README.md に載ってる CI のバッジでの最終ビルド結果は見ても、そこから CI のサイトで、最新の Rails や Ruby のバージョンでビルドしてることまで見るんだろうか?
自分は毎回そこまで見ていない気がするし、そうしてくれたら嬉しいけど、そこまでを分化としていくのは難しい気がする。
となると、やはり何らかの証拠を作者が残すしかない。
1. バージョン上げる
確実だし、Github にも Rubygems.org にも証拠が残る。
自分の基本的なバージョン指針は「0.0.1 が開発中、たまに 0.5.x とか 0.9.x で Pre-release や RC を経て、最初の想定していた機能ができたら、1.0.0 としてリリースし、その後は、機能追加でマイナーバージョンをあげて、バグフィックスなどの機能を追加しない修正はリビジョン(tiny)を上げる」というものなんだけど、この場合リビジョン上げるていいのかどうか悩む。
ソースコードに変更がないのにいたずらにバージョンを上げるべきじゃないと思うし、バージョンあげてしまうと利用者全員に自分と同じような作業が発生する可能性がある。なのでバージョンは上げたくない。
自分の基本的なバージョン指針は「0.0.1 が開発中、たまに 0.5.x とか 0.9.x で Pre-release や RC を経て、最初の想定していた機能ができたら、1.0.0 としてリリースし、その後は、機能追加でマイナーバージョンをあげて、バグフィックスなどの機能を追加しない修正はリビジョン(tiny)を上げる」というものなんだけど、この場合リビジョン上げるていいのかどうか悩む。
ソースコードに変更がないのにいたずらにバージョンを上げるべきじゃないと思うし、バージョンあげてしまうと利用者全員に自分と同じような作業が発生する可能性がある。なのでバージョンは上げたくない。
2. CIを空コミットで回す
Github には証拠が残る。Rubygems.org はそのまんま。
コミットメッセージに「Railsバージョンアップによる確認のための空コミットだよ」みたいなコメントを残しておけばわかりやすい。
コミットメッセージに「Railsバージョンアップによる確認のための空コミットだよ」みたいなコメントを残しておけばわかりやすい。
3. README.mdにログを残す
Github には証拠が残る。Rubygems.org はそのまんま。
基本的に Changelog は書いてるので、そこに追記するか、Change してねーだろってんなら Activity log みたいなセクションを設けて記述する。
Github まで行って README.md 読まない奴はあまりおらんだろうという想定。
ファイルの最終更新まで変更されるし自動的にコミットも伴うから、空コミットより訪問者にわかりやすい。
しかし、普通そういうログは確認後に残すものだから Travis 回して確認 → ログ書いて commit, push はめんどくさい。
基本的に Changelog は書いてるので、そこに追記するか、Change してねーだろってんなら Activity log みたいなセクションを設けて記述する。
Github まで行って README.md 読まない奴はあまりおらんだろうという想定。
ファイルの最終更新まで変更されるし自動的にコミットも伴うから、空コミットより訪問者にわかりやすい。
しかし、普通そういうログは確認後に残すものだから Travis 回して確認 → ログ書いて commit, push はめんどくさい。
まあ、普通に考えたら 2 かな?というわけで、空コミットするお仕事に戻ります。
0 件のコメント :
コメントを投稿