Go におけるパッケージバージョニングに関するプロポーザル

2018-03-26

Go におけるパッケージバージョニングに関するプロポーザル #

A Proposal for Package Versioning in Go by Russ Cox

はじめに #

8年前、Go チームは goinstall （のちの go get）や今日の Go 開発者にはお馴染みの分散化された URL のようなインポートパスを導入しました。goinstall をリリース後、最初に尋ねられた質問の一つにバージョン情報をどのようにして組み込むかというものがありました。私たちは分からなかったことを認めました。長いあいだ、私たちはパッケージのバージョニング問題はアドオンツールで解決するのが一番良いと考えており、人々にアドオンツールを作ることを勧めました。Go コミュニティは異なるアプローチでたくさんのツールを作りました。それにより私たちはその問題についてより深く理解することができ、2015年半ばまでにその問題には多くの解決方法があることが明らかとなりました。私たちは公式のツールをただ一つ採用する必要がありました。

2015年7月の GopherCon から同年秋までに行われたコミュニティでの議論の後、私たちはどのバージョンを使うか決めるために Rust の Cargo におけるタグ付きのセマンティックバージョニングやマニフェスト、ロックファイル、 SAT ソルバー に代表されるパッケージのバージョニングに関するアプローチに従うという結論に至りました。このおおまかな計画に従い、go コマンドに統合するためのモデルとして役立てることを意図した Dep を作るために Sam Boyer はチームを先導しました。しかし、Cargo/Dep アプローチの論理包含についてより深く理解するにつれて、Go が細部（特に後方互換性に関する）を変更することで恩恵を受けることが明らかとなりました。

互換性への影響 #

Go 1 の最も重要な新しい特徴は言語に関するものではありませんでした。Go 1 は後方互換性を重視していました。それまで約一か月毎に安定板のスナップショットをリリースしており、それぞれのリリースによる変更は互換性を極めて欠くものでした。Go 1 のリリース後すぐに、利益や採用において著しい加速を観測しました。互換性に関する約束事 により、開発者たちがプロダクションユースで Go を採用するとより一層快適になると考えています。またその約束事が、今日 Go の人気が高まっている主な理由だと考えています。2013年以降 Go の FAQ は、パッケージの開発者に自らのユーザーが似たような互換性として期待していることを提供するよう促してきました。私たちはこれを インポート互換性のルール（import compatibility rule） と呼んでいます。「古いパッケージと新しいパッケージが共に同じインポートパスを持つ場合、新しいパッケージは古いパッケージに対する後方互換性がなければならない。」

それとは無関係に、セマンティックバージョニング は Go を含む多くの言語コミュニティにおいてソフトウェアのバージョンを記述するデファクトスタンダードとなりました。セマンティックバージョニングを用いることで、単一のメジャーバージョン内では後方のバージョンは前方のバージョンと後方互換性が保たれていることが期待されます。例えば、v1.2.3 は v1.2.1 や v1.1.5 と互換性がなければならないですが、v2.3.4 はそれらのいずれかと互換性がある必要はありません。