松浦 知也 Matsuura Tomoya
e10339dbf6
All checks were successful
Build / build (push) Successful in 14m47s
29 lines
2.3 KiB
Markdown
29 lines
2.3 KiB
Markdown
---
|
||
date: 2026-01-12 08:48
|
||
---
|
||
#thoughts
|
||
|
||
[The Cutting Edge of Versioning (LambdaConf 2024) — Sympolymathesy, by Chris Krycho](https://v5.chriskrycho.com/elsewhere/cutting-edge-of-versioning/)
|
||
|
||
> **バージョン管理はコミュニケーションツールである**
|
||
|
||
> **バージョン管理は*社会技術的契約*である：**
|
||
|
||
パッケージマネージャが導入されることで初めてプログラミング言語はインターネットで繋がれたツールになる。
|
||
|
||
パッケージマネージャは自動で問題を解決してくれるわけではない。なぜなら問題を管理する人間が不完全だからである。
|
||
|
||
バージョン管理は通常[[Semantic Versioning]]で管理されるが、メジャーバージョンは互換性とは別にマーケティング的都合で動かされることもままある。作者がパッチバージョンとマイナーバージョンを間違えてタグづけることもある。Gitで操作した履歴とパッケージマニフェストのバージョン番号が不整合なこともある。
|
||
|
||
どっちかというとこれらの不整合の責任を分離するツールとも言えるかもしれない。
|
||
|
||
例えば[[Homebrew]]は技術的にはあまり良くできたパッケージマネージャではない。どれが依存パッケージかの区別がないので管理が面倒だし、ロックファイルもない(Pythonツールのresourcesのやり方は少しロックファイルっぽいが）。なので基本的にどのツールも複数バージョンの共有を許さないため、依存ツール間でバージョンの不整合が起きると死ぬことがある。だがなんだかんだ割とよく使われてて成立している。それがなぜかというと、Pull Requestベースのレビューでリポジトリが中央集権管理されていて、また管理がよく行き届いていてユーザーが多いから、というややトートロジー的な理由である。
|
||
|
||
不整合は起きるかもしれないが、起きたら起きたでユーザーからの報告がすぐ届いて、対応も早い。運用でうまいことツールの不出来さをカバーしている。そのぐらいの複雑度だから多くの人が運用に参加できているとも言える。
|
||
|
||
|
||
|
||
|
||
|
||
|