← Semua pembelajaran / Go Nol → Enterprise
Fase 11 · Enterprise & Capstone

Versi, kompatibilitas & strategi upgrade

Go 1 Compatibility Promise membuat upgrade Go termasuk yang paling mudah di antara bahasa mana pun. Yang tetap butuh disiplin adalah dependensi, dan menjaga jarak dari versi yang sudah tidak didukung.

Sumber asli go.dev Resmi Rangkuman ~6 menit baca

Intisari

  • Rilis mayor tiap Februari dan Agustus; satu versi didukung sampai ada dua versi lebih baru.
  • Go 1 Compatibility Promise: program yang kompilasi di 1.x akan tetap kompilasi di 1.y — upgrade biasanya nol perubahan kode.
  • Baris go di go.mod menentukan versi bahasa; toolchain bisa lebih baru.
  • go fix (Go 1.26) memodernisasi kode ke idiom terbaru secara otomatis (Fase 0).
  • Naik setiap rilis lebih murah daripada melompat tiga versi sekaligus.

Jadwal dan dukungan

VersiRilisDukungan berakhirYang menonjol
1.22Feb 2024Feb 2025Routing ServeMux, variabel loop per iterasi
1.23Agu 2024Agu 2025Iterator (range atas fungsi)
1.24Feb 2025Feb 2026Direktif tool, os.Root, b.Loop
1.25Agu 2025Agu 2026GOMAXPROCS sadar container, testing/synctest
1.26Feb 2026Feb 2027Green Tea GC, go fix modernizer, new(expr)

Aturannya satu kalimat: sebuah rilis didukung sampai ada dua rilis mayor yang lebih baru — jadi kamu punya sekitar satu tahun per versi. Berjalan di versi yang sudah tidak didukung berarti tidak ada lagi perbaikan keamanan untuk runtime dan pustaka standar, dan govulncheck (Fase 8) akan terus melaporkan temuan yang tidak bisa kamu perbaiki tanpa naik versi.

Go 1 Compatibility Promise

Yang dijanjikan:
  program yang kompilasi dan berjalan benar di Go 1.x
  akan tetap kompilasi dan berjalan benar di Go 1.y (y > x)

Yang TIDAK tercakup:
  • perbaikan bug keamanan yang mengubah perilaku
  • detail implementasi yang tidak pernah dispesifikasikan
    (urutan map, layout struct, presisi penjadwalan)
  • paket yang ditandai eksperimental
  • perubahan yang dikendalikan GODEBUG
# Kalau sebuah perubahan perilaku menggangumu, GODEBUG mengembalikan
# yang lama sementara — memberi waktu memperbaiki kode.
GODEBUG=httplaxcontentlength=1 ./server

// atau tetapkan per modul
//go:debug httplaxcontentlength=1

Mekanisme GODEBUG inilah yang membuat janji kompatibilitas bisa dipegang tanpa membekukan bahasa. Perubahan perilaku yang berpotensi merusak selalu datang dengan saklar untuk mengembalikan perilaku lama — dan saklar itu bertahan beberapa rilis, sehingga upgrade tidak pernah jadi ultimatum.

Alur upgrade

# 1. Naikkan toolchain lokal
go install golang.org/dl/go1.26.5@latest && go1.26.5 download

# 2. Naikkan baris go di go.mod (setelah CI hijau)
go mod edit -go=1.26.0

# 3. Modernisasi kode ke idiom baru — periksa dulu
go fix -diff ./...
go fix ./...

# 4. Gerbang lengkap (Fase 8)
go build ./...
go vet ./...
go test -race ./...
golangci-lint run
govulncheck ./...

# 5. Naikkan dependensi — patch dulu, terpisah dari upgrade Go
go get -u=patch ./...
go mod tidy
go test -race ./...

# 6. Perbarui versi di Dockerfile dan workflow CI

Pisahkan menjadi beberapa commit: naikkan Go, jalankan go fix, naikkan dependensi — masing-masing sendiri. Kalau ada yang rusak, kamu langsung tahu penyebabnya. Upgrade yang menggabungkan ketiganya jadi satu diff raksasa adalah upgrade yang tidak bisa di-review dan tidak bisa di-bisect.

Menaikkan dependensi

go get -u=patch ./...           # hanya patch — paling aman, jalankan rutin
go get -u ./...                 # sampai minor — baca catatan rilisnya
go get [email protected]           # mayor — jalur import berubah (Fase 0)

go list -m -u all               # apa saja yang punya versi lebih baru
go mod why -m pustaka           # kenapa ia ikut terbawa
KadensiYang dilakukan
Mingguan (otomatis)-u=patch untuk dependensi langsung; merge kalau CI hijau
BulananNaik minor; baca catatan rilis
Per rilis Go (2× setahun)Naik Go + go fix
SegeraApa pun yang dilaporkan govulncheck

Biaya upgrade tumbuh lebih cepat daripada linear terhadap waktu yang ditunda. Naik satu versi Go biasanya nol perubahan kode dan sore hari selesai. Melompat dari 1.21 ke 1.26 berarti lima rilis perubahan perilaku sekaligus, dependensi yang sudah menjatuhkan dukungan, dan tidak ada cara memisahkan penyebab saat ada yang rusak.

Memberi versi pada API-mu sendiri

Yang diberi versiCara
API HTTP publikAwalan jalur: /api/v1/, /api/v2/
Modul Go (kalau dipublikasikan)Tag semver; v2+ masuk ke jalur import
Kontrak gRPCPaket berversi: katalog.v1
Muatan pesan antreanField versi di dalam muatan
Kunci cacheAwalan versi: produk:v2:{id} (Fase 9)
Skema databaseMigrasi berurutan, kompatibel dua arah (Fase 4)

Muatan antrean adalah yang paling sering terlupa. Saat deploy, pesan yang ditulis kode lama masih ada di antrean dan akan dibaca kode baru — persis seperti masalah migrasi kompatibel dua arah. Beri versi pada muatan, dan pastikan konsumen baru masih bisa membaca format lama selama beberapa rilis.

Daftar periksa umur panjang

  1. Naik versi Go setiap rilis — dua kali setahun, terjadwal.
  2. Otomatiskan pembaruan patch dependensi, dengan CI sebagai gerbangnya.
  3. govulncheck di CI, dan tanggapi temuannya segera.
  4. Jaga suite tes tetap cepat — di atas dua menit, orang berhenti menjalankannya.
  5. Uji arsitektur menjaga batas modul (materi pertama fase ini).
  6. Hapus flag rilis setelah fiturnya stabil.
  7. Catat keputusan — satu berkas ADR pendek per keputusan besar; enam bulan lagi kamu tidak akan ingat alasannya.
  8. Uji pemulihan backup setahun sekali (Fase 10).

Latihan: periksa versi Go di go.mod, Dockerfile, dan workflow CI-mu — pastikan ketiganya sama. Jalankan govulncheck ./... dan go list -m -u all, lalu perbaiki temuan yang ada. Terakhir, jalankan go fix -diff ./... dan baca perubahan yang diusulkannya.

Rangkuman ini sengaja dipangkas ke bagian yang dipakai di roadmap. Buka sumber aslinya saat kamu butuh detail lengkap atau referensi parameter.