より依存パッケージのバージョン指定をしますが、これが壊れている場合が見受けられます。このような問題の解説や、気付いて直すための方法についての話です。前日になっても枠が空いていたので、最近思うところを急遽突っ込むことにしました。前日の記事は『Dhallの型定義からRustの型を自動生成するマクロ』でした。依存バージョンを指定するときは、マイナーバージョンやパッチバージョンまで含めて最新のものを指定しましょう。生成し、ビルドやテストを実行しましょう。依存先に問題を見付けたら報告・修正しましょう。ような不正確な案内をするのをやめましょう。記載するバージョン指定について説明します。該当ページに全て書いてあるのですが。基いて互換性のあるバージョンを許容する制約です。省略可能なので、単にバージョン番号を書いた場合はこの解釈になります。その代わりに使えるバージョンを使う」という意味になります。出た場合、それらのバージョンも選択肢に入ります。より指定する方法もあります。(ただし誤りの修正を意味するパッチバージョンを除く)。これを受け入れません。頼んでない」というわけです。通常のユーザが利用する必要のないものです。ユーザとしてこの指定を利用するのは賢明ではありません。よって本記事ではこれ以上の言及はしません。以外による指定についても同様に、本記事では言及しません。互換性を大事にしていますが、それでも互換性破壊が起きることはあります。開発者に一任されており、コンパイラや言語仕様の都合ばかりでなく、開発者が見落としや誤ったバージョン付けを行った場合でもユーザがその被害を被ることになります。具体例を見てみましょう。使われているのがわかる。伝えることになります。等の機会に、利用可能な中で最新のバージョンを取得します。最新で、これが利用されていることがメッセージからわかります。実際に確認してみましょう。使われているのがわかる。これに対応しておらず、結果コンパイルエラーとなるのです。事前にこれに対処することはできません。後から壊れてしまったビルドは、後世の人々が気付いて修正するしかないのです。指定してやれば問題なくコンパイルが通るであろうと予想できます。ついても、サイレントに壊れている場合があります。準備したのにビルドが通らないということです。等により症状が隠れてしまう場合もあり、見逃されがちです。発生要因としては、以下のようなものが考えられます。不必要に緩いバージョンを指定した一番ありそうな原因です。壊れた次いでありそうな原因です。依存自体を回避するようコード書き換えるなりする必要があります。リリースされた後で問題に気付くことは困難です。従わない非互換な更新をしたあまり信じたくはない話ですが、まあ残念ながらなくもないです。その原因は様々で、単に更新内容に見落としがあったとか、互換性破壊が発生することに気付かなかったとか、そもそも互換性破壊に相当するかコンセンサスが形成されていない[2]とか、いろいろ考えられます。気付いたら泣きながら依存バージョンを上げましょう。より問題が顕在化するようになります。それゆえ問題に気付くチャンスも増えるでしょう。壊さない、壊れたことに気付くための方法はいくつかあります。バージョンは不必要に緩くすべきではありません。ように最新のものを指定すべきでしょう。実装と動作確認を行うことになるからです。例に出してもいいかもしれません。ような緩い制約を指定すべきではありません。ここでいうエッジケースとは、すなわち最新のバージョンと最古のバージョンです[3]。ツールチェインが必要です。使う必要はありません。testなどしましょう。有無のバリエーションも含めてテストするのが良いかと思います。有効化したらビルドできなくなったとか悲しいので。ついては無料で利用可能な場合が多いです。最新の依存でビルドできるかだけではなく、制約を満たす最古のバージョンでビルドできるかも自動的に検査しましょう。手動でやることとほとんど変わりません。ツールチェインは不要です。失敗することがあります。このような場合、問題を報告しましょう。気付いたあなたが直すのです。思ったのでこの記事を書いています。同時に壊れていたりなど、解決に手間がかかるケースもあります。報告してしまいましょう。バージョンを記載しましょう。リリース前のバージョン番号更新忘れにも注意です。そもそもの話をしてしまうと、私はあの案内は普通に不要だと思うのです。読んでると思うんですよね。リリース毎に更新すべき箇所を断片的に増やして案の定忘れたりするくらいなら、最初からこんな基礎的で誤りやすい案内はない方がマシだと思います。追加すべき記述は掲載されているわけですからね。使うことでバッヂ画像を取得できます。リンクにしておけば、バージョンの案内としては十分でしょう。壊れることがあります。問題が隠れてしまう場合があります。まで含めて、できるだけ新しいバージョンを明示的に指定しましょう。ような緩い指定をした結果壊れるようでは、ユーザが困ります。ように、追加時点で使おうとしていたバージョンを明示しましょう。記述が壊れていないか検査できます。最小依存バージョンでのビルドを試してみたら失敗することがあるかもしれません。適切に修正してパッチを提供できると尚良いのですが、手間がかかることもあります。報告されていた方が助かるので、気力や余裕がなければ、まずは無理せず報告してみましょう。ような不正確な案内をするのをやめましょう。基礎的すぎて誰に向けた案内なのか微妙なうえ、更新忘れなどのミスも発生しやすくなります。リンクで対応しましょう。ようなものを追加しておくだけです。検査してもらえると、パッチを投げる側としては大変助かります。上げることになっています。挙動や出力を完全に、余すことなく理解している前提でコードを書いている」という場合です。知っているという想定でコードを書く場合などが考えられます。[2]もちろんエッジケースのみの検査で完全ではないのは言うまでもなく、たとえば依存バージョンについて完全な検査をするなら、制約を満たすあらゆる依存バージョンの組み合わせでテストをする必要があります。それは実用的でなく、また最初と最後が問題なければ中間のバージョンも問題ないことがそれなりに期待できることから、妥協して最古と最新のバージョンだけで検査しましょうということです。クソの掃き溜めにするnの。