4.0.2のgemが未リリース

[tdtds]

あとでやる。

[hsbt]

http://rubygems.org/gems/tdiary/versions/4.0.2

リリース済みであります!

[satoryu]

:+1: !!!

[tdtds]

ちゃうちゃう、tdiary-contribが長らくアップデートされてないのよ。

https://rubygems.org/gems/tdiary-contrib

[satoryu]

勘違いして :+1: してしまった…

[hsbt]

今出しておきました!

https://rubygems.org/gems/tdiary-contrib/versions/4.0.2

[tdtds]

後学のためにcontribのgemのリリース手順を教えて下さい。

現在リポジトリにあるGemfile.lockは「tdiary (4.0.1.20131102)」とあるので、そのままrake buildするとtdiary-contrib-4.0.1.20131102.gemができてしまう。ので、

1. まずtdiary gemの新しい版(今回でいえば4.0.2)をリリースする
2. 続いてcontribでbundle updateをして依存関係を最新gemに揃える
3. bundle exec rake build (ないしrelease)でcontrib gemの4.0.2を作ってリリース

で良い?

[hsbt]

あー、すみません。Gemfile.lock まで含めたリリースということまで頭が回ってませんでした。バージョンナンバーを固定すると言う意味で @tdtds が書いている手順で良いと思います。

[tdtds]

じゃあ今のgemはbundle updateしてから再リリースした方がいい?

[hsbt]

ちなみに今の 4.0.2 は 4.0.2 リリース時の tag を checkout してリリースしたものです。

で、Gemfile.lock を直す方法はいくつかあるんですけど、思いつくところだと

• 4.0.2 を yank して 4.0.2 をチェックアウト、bundle update だけ実行して 4.0.2.1 を出す
• 4.0.2 を yank して、今の HEAD を bundle update してから 4.0.2.1 を出す(4.0.2 以降の修正も含む)
• 今のままにして 4.0.3 を 12/29 に頑張る

という流れですね。色々動いてないというのが報告されているので、三つ目が良いと思いますがどうでしょう?

[tdtds]

contribはもともとリリースサイクルに乗っていたものではないが、今回gem化によって(必然的に)特定バージョンのcoreに依存するようになったというだけの話なので、2つ目でいいんじゃないかと思う(バージョンは4.0.2.YYYYMMDDで)。もちろん今問題になっているところは随時直していかないといけないけど、それも非同期でいいでしょう。

あと、Gemfileでtdiary gemのバージョンは固定にした方がいいかもね。

[hsbt]

じゃあ、二つ目でいきましょう。