2023年12月24日、今日はクリスマスイブ🎅🎄⭐です。
今年のクリスマスイブは日曜日、ホリデー、(BEAR)"Sunday"です！一年で一番ロマンチックなこの季節、皆さんも素敵でロマンチックな一日をお過ごしでしょうか。
しかし、この記事ではBEAR.Sundayはロマンチックでなく、セマンティックというお話をします。
Semver
BEAR.Sunday 1.0のリリースは2014年。来年で10年を迎えます。
この1.0のリリースの時に、強い思いで決めていたことがありました。それは破壊的変更(Breaking Change)を行わないということです。
セマンティック バージョニング に従えば、破壊的変更が取り込まれた場合、メジャーバージョンを上げなければなりません。つまりこの先にメジャーバージョンを上げない。例えば "BEAR.Sunday 2.0" や "BEAR.Monday"がもし出ることがあれば、このプロジェクトは部分的あるいは全面的な失敗だとまで考えました。
BEAR.Sundayはずっと1.xでいるということですが、これは進化をしない事を意味している訳ではありません。破壊をしないということです。それにはアイデアや技術が必要ですが、それ以上に良い制約が必要です。
メジャーバージョンアップはお祝いではなく、失敗だと考えるマインドセットが最初からありました。
Romver
Nils Adermann氏とJordi Boggiano 氏によって始められた"composer"が最初に 1.0.0-alpha1 としてリリースされたのは2013年3月です。composer.jsonによる依存パッケージのバージョンニングはsemverを前提としています。 例えば ~1.0のバージョン指定は破壊的変更の行われる2.0 以上のパッケージのインストールは行わないというものです。
ところがcomposerのリリースから数年が過ぎてもこれに従わないパッケージはそんなに珍しいことではありませんでした。例えば Michael Dowling氏の開発したGuzzleはかつてそうでしたし1、他のフレームワークの多くもそうでした。234
では、semverに従ってないバージョンは何を表すのでしょうか？ 最初の数字の意味は何でしょうか。
Romantic ?
Semverに従わず、X.Y.ZのYの変更で破壊的変更を行うバージョニングを『ロマンティック バージョニング』 と呼びます 😅5
しかしバージョン管理をする側からすると、パッケージ毎でバージョンの数字の意味が違うのであれば、それは全然ロマンチックな話じゃありません。どのバージョンがセマンティックで、どれがロマンティックなのかを把握してそれぞれに応じてバージョンアップを管理して、行わないと破壊的変更が取り込まれ既存のソフトウエア動作が壊れてしまいます。
Jordiさんに直訴?
(これでしょとBEAR.Sundayご存知だったJordiさん)
composerの作者、Jordiさんが2016年に来日した時 6 に「Semverに従うのが理想であってもRomverを使うパッケージがある現実がある以上、それに対応する必要があります！」みたいな話をして、自分の使ってるバージョニングはセマンティックなのかロマンチックなのか宣言すれば良いのでは、とこのような"versioning-type"の仕様を提案をしました。
My question is that how do we know which framework (or library) follows which versioning ? Romantic versioning gives little value for the dependency management ?
— Akihito Koriyama (@koriym) May 18, 2018
しかし「composer.jsonのバージョニングはsemver前提だ！」 と却下されました。（当然）
非破壊的進化
BEAR.Sundayはバージョン1.xのままです。破壊的変更をしないという約束はこの10年守られました。
どのように守ったのか？
PHPのメジャーバージョンアップ、サポートPHPバージョンのドロップ、全体をロックしないバージョニング、追加機能、使わなくなった機能、複雑性、リファクタリング、テストや静的解析、型システムの変化
どのようなマインドセット、アイデア、技術で対応して、非破壊的な変更を避け進化可能性（evolvability）を保ったのか...次回の記事に続きます。
それでは皆さん、セマンティック、じゃなくてロマンチックな週末をお過ごしください。Merry Christmas！🎄✨
P.S.
ところで、ロマンチックだったら"セマンチック"でも良いと思うのですが？？