Package.json vs go.mod: Wohin ist das Versionsfeld verschwunden?
Wenn du von JavaScript zu Go wechselst, wird dich eine Sache überraschen.
Öffne eine package.json-Datei. Du wirst direkt oben ein version-Feld sehen. Es ist leicht zu lesen. Du kannst es in einem Pull Request ändern. Es befindet sich direkt in deinem Code.
Öffne nun eine go.mod-Datei.
Die Version ist nicht da. Das ist kein Fehler. Es ist eine bewusste Entscheidung.
Go verwendet kein Versionsfeld für dein eigenes Modul. Stattdessen werden Git-Tags genutzt.
So funktioniert es:
• Du führst git tag v1.2.3 aus
• Du pushst den Tag in dein Repository
• Dieser Tag wird zu deiner Version
Wenn jemand go get ausführt, schaut Go in deine Git-Tags, um den richtigen Commit zu finden. Der Tag ist die Single Source of Truth.
Dieses Design hat eine große Stärke. Eine Version kann niemals auf den falschen Code verweisen. Bei npm können der veröffentlichte Code und das Versionsfeld auseinanderdriften. In Go sind sie dasselbe. Die Version ist der Commit.
Dies verändert jedoch deinen Workflow:
- Sichtbarkeit: Du kannst deine Version nicht einfach durch das Betrachten einer Datei sehen. Du musst einen Git-Befehl ausführen, um sie zu finden.
- Code-Reviews: Ein Version Bump erscheint nicht in einem Code-Diff. Es ist ein Tag-Push, keine Code-Änderung.
- Lokale Builds: Ein Commit ohne Tag zeigt eine unübersichtliche Pseudo-Version an. Erst nachdem du den Commit getaggt hast, erhältst du eine saubere Version.
- Major-Versionen: Das ist die größte Änderung. In Go müssen v2 und höher die