Contoh release notes untuk setiap jenis perubahan

Contoh release notes terbaik itu singkat, menyebut siapa yang terdampak, dan menjelaskan apa yang harus dilakukan berikutnya. Di bawah ini ada satu contoh untuk setiap jenis perubahan yang akan Anda rilis, beserta alasan mengapa contoh itu berhasil, sehingga Anda bisa menyalin bentuknya dan mengganti faktanya dengan milik Anda.

Semua contoh adalah rekaan, untuk aplikasi invoice fiktif bernama Tidepool.

Apa kesamaan contoh release notes yang baik?

Semuanya memberi tahu pengguna apa yang berubah dan apa yang harus dilakukan, jika ada, dengan bahasa pengguna. Setiap jenis perubahan punya tugas berbeda, jadi bentuknya bergeser di antara mereka.

Seperti apa catatan fitur baru yang baik?

Catatan fitur yang baik dibuka dengan apa yang sekarang bisa dilakukan pembaca dan menyebut paket atau peran yang mendapatkannya. Ia melewatkan detail implementasi.

Kirim invoice dalam bahasa pelanggan. Sekarang Anda bisa memilih bahasa untuk setiap pelanggan, dan invoice, pengingat, serta halaman pembayaran mereka mengikutinya. Bahasa Prancis, Jerman, Spanyol, dan Portugis tersedia di semua paket. Atur di halaman pelanggan, di bawah Preferensi penagihan.

Judulnya adalah frasa yang akan diucapkan pembaca dengan lantang, dan isinya memberi cakupan dan lokasi. Pembaca yang hanya memindai baris tebal tetap tahu apa yang dirilis. Metode yang lebih luas ada di cara menulis release notes.

Seperti apa catatan peningkatan yang baik?

Catatan peningkatan menjelaskan perubahan yang akan dirasakan pembaca, dan menaruh angka terukur jika ada. Tanpa angka, sebutkan apa yang tidak perlu lagi dilakukan pembaca.

Daftar invoice dimuat sekitar tiga kali lebih cepat. Akun dengan lebih dari 5.000 invoice dulu menunggu sekitar sembilan detik untuk daftarnya. Sekarang terbuka dalam sekitar tiga detik. Tidak ada tindakan yang diperlukan.

“Peningkatan performa” tidak memberi tahu pembaca apa-apa, sedangkan sembilan detik lawan tiga adalah klaim yang bisa mereka cek Senin pagi. Penutup “Tidak ada tindakan yang diperlukan” menjawab pertanyaan yang dimiliki setiap pembaca.

Seperti apa catatan perbaikan bug yang baik?

Catatan perbaikan bug menjelaskan gejala yang dilihat pengguna, bukan penyebab di kode, dan menyebut apakah mereka perlu mengulang sesuatu. Perbaikan yang tidak disadari siapa pun bisa masuk ke daftar di bagian bawah.

Diperbaiki: email pengingat terkirim dua kali pada tanggal jatuh tempo. Sebagian pelanggan menerima dua pengingat identik jika invoice mereka jatuh tempo pada hari terakhir bulan. Ini sudah diperbaiki. Pengingat yang sudah terkirim tidak terpengaruh, dan tidak ada yang perlu mengirim ulang apa pun.

Judulnya diawali “Diperbaiki” sehingga pemindai bisa memilahnya sekilas, dan kondisi sebenarnya (hari terakhir bulan) langsung mengikuti.

Bagaimana menulis release notes untuk breaking change?

Catatan breaking change dibuka dengan tanggal dan kelompok yang terdampak, lalu memberi migrasi dalam entri yang sama. Letakkan paling pertama dalam release notes, karena ini satu-satunya entri yang tidak boleh terlewat pembaca.

Tanda tangan webhook menjadi wajib pada 1 Desember 2026. Mulai tanggal itu Tidepool berhenti mengirim payload webhook tanpa tanda tangan. Ini berdampak pada siapa pun yang menerima webhook tanpa memeriksa header Tidepool-Signature. Untuk bermigrasi, verifikasi header dengan secret di Pengaturan, Developer. Jika Anda sudah memverifikasi tanda tangan, tidak ada tindakan yang diperlukan.

Tanggalnya ada di judul, sehingga bertahan saat dipindai. Kelompok yang terdampak disebut menurut apa yang mereka lakukan, dan kalimat terakhir membebaskan orang yang sudah aman, yang mengurangi beban support. Panduan tentang breaking changes membahas cara memutuskan apakah suatu perubahan termasuk.

Seperti apa catatan perbaikan keamanan?

Catatan keamanan menyebut apa yang terekspos, apakah ada yang mengeksploitasinya, siapa yang terdampak, dan apa yang harus mereka lakukan. Tetap faktual dan tenang.

Keamanan: tautan reset password bisa dipakai ulang. Antara 3 dan 17 September 2026, tautan reset password tetap valid setelah dipakai sekali. Kami tidak menemukan tanda bahwa ini dieksploitasi. Sudah diperbaiki, dan semua tautan reset yang belum terpakai telah dibatalkan. Jika Anda meminta reset dalam rentang itu, minta tautan baru.

Rentang waktu yang tepat membuat pembaca bisa menilai paparan mereka sendiri, dan kalimat tentang eksploitasi menjawab pertanyaan pertama yang diajukan siapa pun. “Potensi masalah” terdengar seperti menutup-nutupi, jadi nyatakan apa yang Anda ketahui.

Bagaimana menulis pemberitahuan deprecation?

Pemberitahuan deprecation menyebut apa yang akan dihapus, memberi tanggal akhir yang tegas, dan menunjuk ke penggantinya.

Endpoint invoice v1 di-deprecate dan berakhir pada 1 Maret 2027. GET /v1/invoices tetap berfungsi hingga 1 Maret 2027, lalu mengembalikan 410 Gone. Gunakan GET /v2/invoices, yang mengembalikan field yang sama plus currency. Respons dari v1 kini menyertakan header Sunset dengan tanggal akhirnya. Panduan migrasi berdampingan ada di dokumentasi.

Nama endpoint ada di judul, karena orang yang terdampak mencarinya, dan penggantinya diletakkan di samping penghapusan. Header Sunset memberi tahu developer panggilan mana yang masih memakai versi lama. Pembahasan yang lebih panjang ada di mendeprecate API.

Seperti apa catatan rilis app store?

Catatan app store terdiri dari dua atau tiga kalimat sederhana, karena kebanyakan orang hanya membaca baris pertama. Mulai dengan perubahan yang akan disadari pengguna.

Pindai struk kertas dan Tidepool mengisi jumlah, tanggal, dan vendor. Mode gelap kini mengikuti pengaturan ponsel Anda. Kami juga memperbaiki crash saat membuka invoice dari notifikasi.

Perubahan yang paling berguna ada di depan, dan perbaikannya menyebut situasi yang menyebabkan crash. Tidak ada nomor versi dan tidak ada “perbaikan bug dan peningkatan”. Release notes untuk aplikasi mobile membahas aturan khusus store.

Apa yang harus ada di catatan rilis internal?

Catatan internal adalah versi untuk support dan sales. Ia menambahkan apa yang dilewatkan catatan publik: apa yang harus dikatakan, dan apa yang jangan dijanjikan.

Invoice multibahasa dirilis hari ini (semua paket). Support: pelanggan mengatur bahasa di Preferensi penagihan, dan invoice yang sudah ada tetap memakai bahasa aslinya. Bahasa Italia belum tersedia. Sales: ini terbuka untuk setiap paket, jadi jangan memosisikannya sebagai upgrade.

Setiap audiens mendapat baris berlabelnya sendiri, dan catatan itu menarik batasnya (“Bahasa Italia belum tersedia”) sebelum pelanggan bertanya. Artikel release notes internal membahas format dan kanalnya.

Seperti apa release note yang buruk, setelah ditulis ulang?

Release note yang buruk mendaftar apa yang dilakukan tim, bukan apa yang didapat pembaca. Perbaiki dengan memindahkan hasilnya ke depan dan menghapus istilah internal.

Sebelum:

v3.8.1 Merefaktor scheduler pengingat. Memperbaiki race condition di ReminderJob. Memperbarui bull ke 4.12. Peningkatan lain-lain.

Sesudah:

Email pengingat tidak lagi terkirim dua kali. Pelanggan dengan invoice yang jatuh tempo pada hari terakhir bulan bisa menerima dua pengingat. Itu sudah diperbaiki, dan pengingat yang sudah terkirim tidak perlu dikirim ulang. Tidak ada tindakan yang diperlukan.

Juga di 3.8.1: bull diperbarui ke 4.12.

Pembaruan dependensi turun menjadi baris catatan kaki, dan race condition berubah menjadi gejala yang akan dikenali pelanggan.

Bagaimana menjaga release notes tetap konsisten antar rilis?

Susun draf setiap entri saat perubahan di-merge, dan minta seseorang menyetujuinya sebelum rilis.

Changeloop bekerja dengan cara ini: ia membuat draf entri dari setiap pull request yang di-merge dengan AI dan menahannya sampai disetujui manusia. Langkah persetujuan itulah tempat editor menerapkan aturan di atas. Untuk menetapkan formatnya lebih dulu, mulailah dari template release notes, dan lihat contoh changelog untuk melihat seperti apa halaman yang sudah jadi.

FAQ

Apa itu release notes baru? Release notes baru adalah pesan yang diterbitkan bersama rilis terbaru sebuah produk, yang menjelaskan apa yang berubah dan apa yang perlu dilakukan pengguna. Isinya mencakup fitur, peningkatan, perbaikan, dan breaking change.

Apa perbedaan antara release note dan changelog? Changelog menyimpan semuanya, untuk siapa pun yang menginginkan riwayat penuh. Release note memilih dari sana: satu rilis, ditulis untuk pembaca yang sedang menentukan apakah rilis itu penting bagi mereka. Perbandingan lengkapnya ada di changelog vs release notes.

Apa arti release notes? Release notes memberi tahu pengguna apa yang berubah dalam sebuah rilis. Istilah ini mencakup apa pun yang menjelaskan apa yang dirilis, dari teks “What’s New” di app store sampai halaman di situs perusahaan.

Seberapa panjang setiap entri release note? Dua sampai empat kalimat cukup untuk kebanyakan entri: hasilnya, siapa yang terdampak, dan apa yang harus dilakukan. Breaking change atau perbaikan keamanan bisa lebih panjang karena butuh tanggal atau migrasi.

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