Contoh changelog

1. Rilis SaaS rutin

Kasus umum: segelintir perubahan yang terlihat pengguna, tanpa migrasi, tanpa drama. Singkat karena rilisnya kecil, dan menahan dorongan untuk mengisinya adalah sebagian besar keahliannya.

## 20 Agustus 2026

### Baru
- Tampilan tersimpan di kotak masuk. Kunci satu filter sekali dan
  gunakan lagi dari sidebar.

### Ditingkatkan
- Job ekspor sekarang melaporkan progres alih-alih terlihat macet
  di akun besar.

### Diperbaiki
- Anggota yang diundang tidak lagi melihat dasbor kosong sebelum
  login pertama mereka.

2. Rilis API dengan deprecation

Pembaca changelog API mencari satu hal: apakah integrasi mereka akan segera rusak, dan berapa lama waktu yang mereka miliki. Taruh itu di atas dan beri tanggal.

## Acme API 4.2 - 20 Agustus 2026

### Perubahan yang merusak kompatibilitas
- `?page=` dihapus di semua endpoint daftar. Gunakan nilai
  `nextCursor` dari respons sebelumnya.
  `?page=` mengembalikan 400 setelah 1 Oktober 2026.
  Langkah migrasi: acme.example/docs/pagination

### Baru
- Webhook bisa dibatasi ke satu proyek.

### Ditingkatkan
- Endpoint daftar merespons sekitar empat kali lebih cepat di
  akun dengan lebih dari 10.000 catatan.

3. Rilis mobile

App store menampilkan kolom yang-baru yang terpotong, dan review bisa menahan build selama berhari-hari. Kedua fakta ini membentuk entrinya.

## iOS 3.4.0 - 20 Agustus 2026

Mode offline. Buka, baca, dan susun draf tanpa koneksi;
semuanya sinkron saat kamu kembali online.

### Juga di rilis ini
- Peluncuran lebih cepat di perangkat lama.
- Diperbaiki crash saat membuka tautan bersama dari Mail.

4. Perbaikan keamanan

Satu-satunya entri di mana berkata lebih sedikit adalah yang benar. Pengguna perlu tahu mereka harus memperbarui; tidak ada orang lain yang perlu deskripsi yang cukup presisi untuk menyerang versi yang belum mereka perbarui.

## 20 Agustus 2026

### Keamanan
- Memperkuat cara token sesi divalidasi. Akun pada instalasi
  yang dikelola sendiri harus memperbarui ke 4.2.1 atau lebih
  baru. Dilaporkan secara bertanggung jawab; tidak ada bukti
  eksploitasi. Detail: acme.example/security/2026-08

5. Seperti apa contoh yang buruk

Setiap baris di sini nyata bentuknya, dan setiap baris adalah kesalahan:

## v2.3.7

- Menggabungkan PR #482 dari feature/inbox-refactor
- Memperbarui lodash 4.17.20 -> 4.17.21
- Memperbaiki race condition di MembershipCache.resolve()
- Berbagai perbaikan bug dan peningkatan
- Merefactor model SavedView (terima kasih Dave!)

Kesamaan yang bagus-bagus

• Menjelaskan hasil, bukan implementasi. Pembaca yang belum pernah melihat kodenya tetap bisa tahu apakah entrinya memengaruhi mereka.
• Menghilangkan hal-hal. Pembaruan dependensi, refactor, perubahan CI, dan penggantian nama internal tidak ada, dan ketidakhadiran itu yang membuat sisanya mudah dibaca.
• Menaruh hal yang berbiaya lebih dulu. Jika ada yang rusak, itu jadi judul pertama, dengan tanggal.
• Diberi tanggal dengan cara yang bisa dipakai pembaca: nomor versi di tempat pengguna bisa melihat versi, tanggal di tempat mereka tidak bisa.
• Sengaja membosankan. Tanpa tanda seru, tanpa kata sifat pemasaran, tanpa "kami senang mengumumkan". Orang yang membaca changelog mencari informasi dan akan kesal dengan apa pun yang menghalanginya.

Pertanyaan umum

Format apa yang harus dipakai changelog?

keepachangelog.com paling mendekati standar dan nama bagiannya (Added, Changed, Deprecated, Removed, Fixed, Security) dikenal luas. Ini jauh lebih tidak penting dibanding cara penulisan di dalam bagiannya. Format konsisten dengan entri samar lebih buruk daripada format longgar dengan entri spesifik.

Seberapa sering kami harus mempublikasikan?

Dengan ritme apa pun yang cocok dengan rilismu, dan konsisten. Mempublikasikan per rilis adalah aturan paling sederhana. Mengelompokkan sebulan rilis jadi satu post membuat setiap perubahan individual lebih sulit ditemukan nanti, padahal itulah saat kebanyakan orang benar-benar membaca changelog.

Haruskah changelog ada di situs kami sendiri atau di halaman pihak ketiga?

Di situsmu sendiri jika bisa, karena di situlah trafik dan nilai pencarian terkumpul, dan karena changelog di domain orang lain berjarak satu tautan dari produkmu alih-alih menjadi bagiannya. Itulah alasan menyajikannya sebagai feed yang kamu render sendiri, alih-alih halaman hosting yang kamu tautkan.

Apakah pengguna benar-benar membaca changelog?

Sebagian kecil membacanya secara rutin dan sebagian jauh lebih besar mencarinya pada saat sesuatu berubah di bawah mereka. Kelompok kedua itulah alasan untuk menulis gejalanya alih-alih penyebabnya: mereka mencari apa yang terjadi pada mereka, dengan kata-kata mereka sendiri.

Bacaan lebih lanjut: changelog vs catatan rilis, dan Keep a Changelog, benar-benar diterapkan.