Pertanyaan Bagaimana seharusnya merilis catatan ditulis?


Adakah pedoman atau praktik terbaik tentang bagaimana catatan rilis harus ditulis? Saya kira saya mencoba menemukan keseimbangan yang tepat antara membuat poin tanpa terlalu spesifik. Juga, apakah pengembang biasanya menyediakan lebih banyak catatan rilis untuk tim QA dibandingkan dengan yang diajukan untuk tampilan publik?


37
2018-03-12 12:35


asal


Jawaban:


Catatan rilis publik harus berisi setidaknya:

  • lepaskan, buildnumber
  • semua bug publik tetap
  • semua fitur publik ditambahkan

Catatan rilis QA setidaknya harus berisi:

  • lepaskan, buildnumber
  • semua bug tetap termasuk nomor bug
  • semua fitur tambahan termasuk tautan ke dokumen desain

Pertimbangkan audiens Anda dan coba pikirkan apa yang mereka butuhkan.

Hal lain yang perlu ditambahkan adalah dukungan baru atau penghentian untuk platform tertentu. (Sebagai contoh, kami menghentikan dukungan untuk Win3.1 dan menambahkan Vista 64 bit).


26
2018-03-12 12:41



Saya akan melihat catatan rilis proyek F / OSS populer:

Semua proyek ini memiliki catatan rilis yang mudah dibaca dan seimbang.


21
2018-03-12 12:42



Jika Anda memiliki sistem manajemen proyek / pelacakan masalah, Anda pasti harus menggunakannya untuk membuat catatan rilis Anda. Trac dan Redmine khususnya sangat baik dalam hal ini.

Titik rilis harus memiliki beberapa properti, IMO:

  • Ingat audiens Anda. Jika ini adalah aplikasi iPhone, sedikit yang akan peduli tentang fakta bahwa kesalahan logika tertentu pada baris 572 di kelas Foo telah diperbaiki. Tapi mereka akan sangat peduli tentang "app sekarang accelerometer-sensitive".
  • Rangkumlah perkembangan, fitur, dan perbaikan bug baru dengan cara yang luas dan menyapu jika memungkinkan. Jika Anda dapat mengikatnya bersama-sama secara tematis (misalnya "kami menerapkan jenis generik dan anonim"), uraian singkat tentang itu adalah cara yang baik untuk memberikan gambaran besar kepada orang-orang.
  • Rinci hal-hal spesifik yang telah diperbaiki, dengan tautan ke pelacak bug publik Anda, jika ada. Ini biasanya dapat dihasilkan secara otomatis.
  • Jangan berikan detail yang mengerikan. Ringkasan satu atau dua-liner dari setiap hal yang ditambahkan atau diperbaiki harus cukup.
  • Selalu sertakan pengenal rilis tertentu (mis. "V.1.4.5"), jika perlu.

11
2018-03-12 12:41



Itu benar-benar tergantung pada penonton. Untuk pengguna teknis (misalnya pengembang yang menggunakan API Anda), Anda bisa sangat teknis. Di ujung lain pengguna akhir tingkat tinggi dari aplikasi yang Anda buat mungkin hanya tertarik pada fitur baru dan perubahan besar.

Di antaranya adalah pengguna non-teknis yang membutuhkan detail juga, misalnya departemen dukungan. Untuk orang-orang itu Anda dapat memberikan deskripsi mendetail tanpa spesifikasi teknis tingkat rendah, misalnya "Memperbaiki bug tempat catatan tidak disimpan dalam database.".


2
2018-03-12 12:42



Salah satu praktik terbaik dengan catatan rilis menurut saya adalah otomatisasi. Jika ada praktik terbaik tertentu untuk sistem kontrol revisi, kirimkan pesan (http://drupal.org/node/52287), Anda dapat membuat catatan rilis dengan skrip otomatis (http://cvs.drupal.org/viewvc.py/drupal/contributions/tricks/cvs-release-notes/). Ini akan menciptakan catatan rilis yang benar-benar bagus: http://drupal.org/node/226165


1
2018-03-12 12:46



Kontributor Utama Catatan Rilis adalah tim pengembangan Anda. Ini adalah praktik yang baik untuk memungkinkan pengembang dan penguji Anda untuk menangkap setiap catatan rilis informasi terkait terhadap pekerjaan AndaItem yang terkait dengan changesets di TFS.

Maka Anda dapat menggunakan proyek open source seperti http://tfschangelog.codeplex.com untuk menghasilkan catatan rilis. Ini memiliki versi GUI dan versi baris perintah yang membuatnya mudah untuk menjadwalkan laporan catatan rilis Anda setiap malam.


0
2018-06-05 12:33