Release notes perangkat lunak: apa itu dan apa isinya

Release notes perangkat lunak adalah dokumen yang menyertai sebuah versi perangkat lunak dan memberi tahu pembaca apa yang berubah di dalamnya, siapa yang terdampak, dan apa yang harus mereka lakukan, jika ada. Release notes ditulis sekali per rilis dan dibaca oleh orang yang menimbang apakah akan upgrade, orang yang memeriksa apakah masalah yang mereka alami sudah diperbaiki, dan orang yang mendukung produknya. Yang baik singkat, spesifik untuk versinya, dan jujur tentang apa pun yang merusak.

Apa itu release notes perangkat lunak?

Release notes adalah ringkasan bertanggal dan berversi dari satu rilis. Sebuah catatan rilis menjawab tiga pertanyaan bagi pembaca yang tidak ikut dalam rapatnya: apa yang berbeda, apakah itu memengaruhi saya, dan apakah saya perlu bertindak. Riwayat lengkap proyek adalah changelog, sedangkan log commit untuk orang yang menulis kodenya.

Fakta yang sama bisa muncul di entri changelog dan di release notes. Bedanya ada pada seleksi dan pembaca: changelog mencantumkan setiap perubahan penting, sedangkan release notes membuka dengan perubahan yang akan disadari pembaca lalu menjelaskannya. Changelog vs release notes menarik garisnya secara rinci.

Apa yang harus ada di release notes perangkat lunak?

Cantumkan versi dan tanggal, ringkasan satu paragraf, lalu perubahan yang dikelompokkan menurut apa yang bisa dilakukan pembaca dengannya. Untuk setiap perubahan, sebutkan apa yang berbeda dalam istilah pembaca, siapa yang terdampak, dan apakah perlu tindakan.

Satu set yang lengkap punya bagian berikut:

1. Nomor versi dan tanggal rilis. Pakai format yang dipakai tag Anda, supaya pembaca bisa mencocokkan catatan dengan build.
2. Ringkasan. Dua atau tiga kalimat: untuk apa rilis ini, dan apakah upgrade membutuhkan sesuatu dari pembaca.
3. Fitur baru dan peningkatan. Apa yang sekarang bisa dilakukan pembaca, bukan apa yang sekarang ada di kode.
4. Perbaikan. Gejala yang hilang dan versi tempat gejala itu mulai muncul.
5. Breaking changes dan deprecation. Apa yang berhenti berfungsi, kapan, dan apa penggantinya. Taruh ini di bagian pertama jika ada.
6. Masalah yang diketahui. Apa pun yang dirilis yang Anda tahu belum benar, beserta solusi sementara jika ada.
7. Persyaratan dan langkah upgrade. Platform yang didukung, versi minimum, perintah migrasi.

Tinggalkan refactor, pembaruan dependensi tanpa efek yang terlihat, dan tiket internal. Jika pembaca tidak bisa menyadari perubahannya, tempatnya di riwayat git. Cara menulis release notes membahas pilihan kata dan urutan.

Seperti apa release note perangkat lunak?

Berikut contoh singkat untuk alat baris perintah fiktif. Bentuknya lebih penting daripada isinya.

## 2.4.0 (2026-10-08)

Faster exports and one breaking change to the config file. Upgrade
needs a one-line edit to `tool.yml`.

### Breaking
- `output:` in `tool.yml` is now `export.path:`. Old configs fail
  with "unknown key". Rename the key; nothing else changes.

### New
- Exports stream to disk, so files over 100 MB no longer time out.

### Fixed
- Search works again for queries containing a hyphen. Broken
  since 2.3.0.

### Known issues
- Windows paths longer than 260 characters still fail. Use a
  shorter output directory for now.

Breaking change ada di urutan pertama, lengkap dengan teks error persis yang akan dilihat pembaca, karena orang mencari pesan error. Perbaikannya menyebut versi tempat ia rusak, sehingga pembaca bisa mencocokkannya dengan kapan masalah mereka dimulai. Masalah yang diketahui punya solusi sementara, yang lebih baik daripada diam. Contoh release notes memuat lebih banyak rumusan untuk tiap jenis entri.

Apa bedanya release notes perangkat lunak untuk tiap pembaca?

Simpan satu sumber kebenaran dan tulis satu versi per pembaca. Faktanya tidak berubah, tetapi tingkat detailnya berbeda. Pelanggan menginginkan manfaatnya dalam satu baris, administrator menginginkan persyaratan dan masalah yang diketahui, developer menginginkan nama dan versi yang persis, dan support ingin tahu apa yang harus dikatakan ketika tiket masuk.

Untuk produk API, versi developer paling perlu dijaga, karena perubahan yang bagi Anda perbaikan kecil bisa jadi gangguan layanan bagi pemanggil. Changelog API dan breaking changes membahas pembaca itu. Untuk versi internal, release notes internal menjelaskan apa yang dibutuhkan support dan penjualan yang tidak dibutuhkan pelanggan.

Di mana release notes perangkat lunak sebaiknya diterbitkan?

Terbitkan di tempat pembaca sudah berada ketika mereka bertanya. Untuk app mobile, itu halaman toko, tempat platform menyediakan kolom release notes untuk setiap versi; Apple mendokumentasikan cara memberi release notes untuk build. Untuk produk web, itu halaman changelog yang ditautkan dari app. Untuk library, itu halaman rilis dan berkas di repositori, seperti dijelaskan di release notes GitHub.

Beri setiap versi URL yang stabil agar support bisa menautkannya, dan simpan versi lama. Pembaca di versi 2.2 butuh catatan untuk 2.3 dan 2.4 juga. Jika Anda ingin struktur awal, template release notes memberi judul bagian yang bisa disalin.

Seberapa panjang release notes seharusnya?

Sepanjang yang dibutuhkan perubahannya dan tidak lebih. Rilis patch bisa tiga baris. Rilis mayor dengan migrasi butuh satu halaman, dan mungkin panduan migrasi terpisah yang ditautkan dari catatannya. Tesnya adalah apakah pembaca yang hanya memindai layar pertama tahu rilis itu memengaruhi mereka atau tidak. Jika tidak, naikkan ringkasannya dan potong sisanya. Praktik terbaik release notes memuat apa yang bertahan dan apa yang sekadar kebiasaan.

FAQ

Apa itu release notes perangkat lunak? Release notes perangkat lunak adalah ringkasan berversi tentang apa yang berubah di satu rilis, ditulis untuk orang yang memakai atau mendukungnya. Isinya fitur baru, perbaikan, breaking changes, dan apa pun yang harus dilakukan pembaca.

Apa bedanya release notes dan changelog? Changelog adalah catatan berjalan yang lengkap tentang perubahan penting. Release notes adalah pesan tentang satu rilis, dipilih dan ditulis ulang untuk pembaca yang menimbang apakah akan upgrade. Banyak tim menerbitkan entri changelog sebuah versi sebagai release notes-nya.

Siapa yang menulis release notes perangkat lunak? Biasanya product manager, penulis teknis, atau engineer yang merilis perubahannya, dengan orang lain yang meninjau nadanya. Hasil terbaik muncul ketika orang yang paling dekat dengan perubahan membuat drafnya dan orang kedua menyuntingnya demi pembaca.

Apakah rilis minor perlu release notes? Perlu, yang singkat. Bahkan rilis patch harus menyebut apa yang diperbaiki dan apakah pembaca perlu bertindak. Catatan satu baris lebih baik daripada tidak ada, karena “perbaikan bug dan peningkatan” tidak memberi tahu pembaca apa pun.

Klaim teknis dalam artikel ini belum ditinjau secara independen. Jika ada yang keliru, beri tahu kami dan kami akan memperbaikinya.

Terkait di changeloop: Templat catatan rilis, Contoh changelog