最も具体的なソースの取得 

コンパイラインターフェースはプロジェクトで使用されている各 Scala バージョンに対して再コンパイルされるため、そのソースは sbt がサポートするすべての Scala バージョン (Scala 2.8 から Scala の最新バージョンまで) と互換性を維持する必要があります。

これは sbt のメンテナーと Scala コンパイラの作成者の両方にとって大きなコストとなります。

1. コンパイラの作成者は、Scala コンパイラから古い廃止されたパブリック API を削除できません。
2. sbt は Scala コンパイラで定義された新しい API を使用できません。
3. sbt は、すべてのバージョンの Scala コンパイラとのソース互換性を維持し、新機能をサポートするために、あらゆる種類のハッキングを実装する必要があります。

この問題を回避するために、sbt が使用中の Scala バージョンに最も具体的なコンパイラインターフェースのソースのバージョンを取得できるようにする新しいメカニズムが sbt に実装されました。

たとえば、Scala 2.11.8-M2 を使用してコンパイルされたプロジェクトの場合、sbt は次の順序でコンパイラインターフェースのソースの次のバージョンを探します。

1. 2.11.8-M2
2. 2.11.8
3. 2.11
4. デフォルトのソース。

この新しいメカニズムにより、Scala コンパイラと sbt の両方が前進し、新しい API を活用しながら、古いバージョンの Scala のユーザーが引き続き sbt を使用できることを確信できます。

最後に、この手法のもう 1 つの利点は、コンパイラブリッジのソースを取得するために Ivy に依存していることですが、Maven での使用に簡単に移植できることです。Maven は、sbt のメンテナーが sbt のモジュールを配布するために使用したいと考えている配布メカニズムです。