mikutter

一応、mikutter 3.8にはRuby 2.6の対応は入っていないので（使ってるけど）、影響範囲なども考えて3.9に適用したいと思います。

全てのGemに対応することにしたので、頂いたパッチを使わず、Addressableを含む全てのgemのバージョンを問題ない範囲で引き上げました。
また、Delayer、Delayer Deferred、Pluggaloid、Divaも、mikutter 3.9にあわせてリリースしようとしていたものをリリースし、要求するようにしています。
これらのGemがRuby 2.4以上を要求しているため、3.9で実施予定だったRubyの最低動作要件をRuby 2.4にするやつも同時に行いました。

ちゃんと動作しているかは今後経過観察をするとして、バージョンの変化に寄ってパッケージするときに厳しいといったことがあれば教えてください。

バージョン記載更新のパッチ自体は問題ありません。

以下は まとまってないけど将来の参照用に書いておく、というメモ：

パッケージシステムの場合、
mikutter 自身の Gem バージョン指定が実行時にチェックされることはなくて
単に情報として扱われるだけだと思います。
（pkgsrc ではコミットする人が目視確認しているだけ）

なので、
「特定の Gem のバージョンに依存する機能を使っているかどうか」がわかるかどうか、
つまり、
「新たな Gem依存機能のコミットとバージョン記載のコミットがセット」だとわかりやすい、
というくらいです。バージョンが変わること自体が問題になることはそれほどありません。

実際には、gtk2 のように
「とりあえず（bundler 等で取得する場合を考慮して）バグの少なそうな最新を書く」
という場合も多いので難しいのですが、
実行時チェックはないのでとりあえずあとで考えることは可能。

問題は diva や pluggaloid のような gem の場合です。
gem の場合はバージョン依存が実行時にチェックされるので、
テキトーにやると起動すらしなくなってしまいます。
なので、事前に依存記載をチェックして対応する gem もパッケージシステムで更新しておく
（もしくは gem の依存関係記述をパッケージシステムで持っているバージョンで上書きする）
といった作業が発生します。
addressable は diva gem に絡むので、そちらの作業がやや重い、というくらいです。

https://speakerdeck.com/tsutsui/mikutter-nagoya-2018
の 14〜17ページも参照。

merged.