Rilis GitHub: Draft, Notes, dan Binary

Tag saja tidak cukup

Kamu sudah tahu git tag v1.0.0 menandai satu titik di riwayat. Tapi tag mentah itu bisu: ia tidak memberi tahu pengguna apa yang berubah, tidak menyediakan file unduhan, dan tidak tampil cantik di mana pun. GitHub Releases adalah lapisan presentasi di atas tag: satu halaman per versi berisi judul, catatan perubahan, dan lampiran file, persis seperti halaman download software profesional.

Kenapa repot-repot? Karena "rilis" adalah kontrak komunikasi dengan pengguna. Tanpa catatan rilis, pengguna harus membaca puluhan pesan commit untuk tahu apakah versi baru aman di-upgrade. Tanpa binary terlampir, pengguna non-teknis tidak bisa memakai aplikasimu tanpa build sendiri. Release yang rapi mengubah tag bisu menjadi pengumuman yang berguna.

Membuat release dari draft

Alur yang aman: siapkan dulu sebagai draft, periksa, baru publikasikan. Di halaman repo, buka Releases lalu "Draft a new release". Pilih "Choose a tag" dan ketik tag baru misalnya v1.2.0, GitHub akan membuatnya saat release dipublikasikan. Isi judul release (biasanya sama dengan tag) dan tulis catatan perubahan.

Fitur favorit banyak maintainer: "Generate release notes". Satu klik dan GitHub menyusun daftar semua PR yang di-merge sejak release sebelumnya, dikelompokkan dan diberi tautan, plus daftar kontributor baru. Contoh hasilnya:

## What's Changed
* Tambah mode gelap oleh @budi in #42
* Perbaiki crash saat login oleh @siti in #45
## New Contributors
* @andi made their first contribution in #44

Kamu tetap bisa mengedit hasilnya: tambahkan sorotan fitur utama di atas, atau peringatan breaking change. Aturan mainnya: notes otomatis untuk kelengkapan, tulisan manual untuk hal yang benar-benar penting.

Melampirkan binary

Bagian "Attach binaries" memungkinkanmu mengunggah file apa pun: installer .exe, .apk, arsip .zip, atau checksum. Ini memisahkan dengan elegan dua kebutuhan: kode sumber tetap di Git (ramping), file jadi didistribusikan lewat release (tidak menggelembungkan repo). Inilah jawaban yang benar untuk "di mana menaruh file APK hasil build?" Bukan di-commit ke repo, melainkan dilampirkan ke release.

Alternatif via CLI dengan GitHub CLI:

gh release create v1.2.0 --generate-notes dist/app.apk

Satu perintah membuat tag, release, notes otomatis, dan melampirkan file. Flag --draft menambahkannya sebagai draft kalau belum siap publikasi, dan --prerelease menandainya sebagai versi beta.

Kapan memakai draft dan prerelease

Pakai draft saat release butuh persiapan bertahap: misalnya tim QA perlu mengunduh binary dari draft internal sebelum pengumuman publik. Pakai prerelease (atau tag seperti v2.0.0-beta.1) saat versinya belum stabil tapi ingin diuji pengguna pemberani. GitHub menandai keduanya dengan label jelas sehingga tidak ada yang salah mengira versi beta sebagai versi stabil.

Satu catatan penomoran: ikuti semantic versioning (major.minor.patch). Naikkan major untuk breaking change, minor untuk fitur baru yang kompatibel, patch untuk bugfix. Konsistensi ini membuat catatan rilismu bisa dibaca mesin dependency seperti Dependabot.

Kesalahan umum pemula

Salah: membuat tag v1.0 lewat command line lalu bingung kenapa tidak muncul apa-apa di halaman Releases. Tag Git dan GitHub Release adalah dua hal berbeda; tag hanya muncul di Releases kalau kamu membuatnya dari sana (atau via gh release create). Benar: untuk pengumuman versi yang proper, selalu buat lewat fitur Releases (atau gh CLI), bukan sekadar git tag.

Salah: meng-commit file binary besar (APK, installer) langsung ke repo "biar gampang diunduh", membuat clone repo makin gendut setiap rilis. Benar: binary besar dilampirkan ke Release, bukan di-commit. Repo tetap ramping, distribusi tetap mudah.