リリース ノートの書き方に関するガイドラインやベスト プラクティスはありますか? 私は、具体的になりすぎずにポイントを作ることの間の適切なバランスを見つけようとしていると思います. また、開発者は通常、公開用に提出されたリリース ノートよりも多くのリリース ノートを QA チームに提供しますか?
Samuel
質問する
43752 次
7 に答える
29
公開リリース ノートには、少なくとも次の情報を含める必要があります。
- リリース、ビルド番号
- すべての修正された公開バグ
- 追加されたすべての公開機能
QA リリース ノートには、少なくとも次の情報を含める必要があります。
- リリース、ビルド番号
- バグ番号を含むすべての修正されたバグ
- 設計ドキュメントへのリンクを含むすべての追加機能
聴衆のことを考えて、彼らが何を必要としているのかを考えてみてください。
追加するもう 1 つのことは、特定のプラットフォームの新規サポートまたは廃止されたサポートです。(たとえば、Win3.1 のサポートを終了し、Vista 64 ビットを追加しました)。
于 2009-03-12T12:41:13.477 に答える
11
プロジェクト管理/問題追跡システムを使用している場合は、必ずそれを使用してリリース ノートを作成する必要があります。特にTracとRedmineはこれが得意です。
リリース ポイントにはいくつかのプロパティが必要です。IMO:
- 聴衆を覚えておいてください。これが iPhone アプリの場合、Foo クラスの 572 行目の特定のロジック エラーが修正されたという事実を気にする人はほとんどいないでしょう。しかし、彼らは「アプリが加速度計に敏感になった」ことを大いに気にするでしょう。
- 可能であれば、新しい開発、機能、およびバグ修正を広範かつ抜本的に要約してください。これらをテーマごとに結び付けることができる場合 (たとえば、「ジェネリックと匿名型を実装しました」)、それについての短い宣伝は、全体像を人々に伝える良い方法です。
- 修正された特定の事項を箇条書きにし、公開されているバグトラッカーへのリンクがある場合はそれを示します。通常、これは自動的に生成されます。
- 耐え難い詳細を提供しないでください。追加または修正された各項目について、1 行または 2 行で要約するだけで十分です。
- 必要に応じて、常に特定のリリース識別子 (「v.1.4.5」など) を含めます。
于 2009-03-12T12:41:42.057 に答える
2
それは本当に聴衆に依存します。テクニカル ユーザー (たとえば、API を使用する開発者) の場合、非常にテクニカルになる可能性があります。一方、作成したアプリケーションの高レベルのエンド ユーザーは、新機能と主要な変更にのみ関心がある場合があります。
その中間には、サポート部門など、詳細情報を必要とする技術者以外のユーザーもいます。それらの人々については、「レコードがデータベースに保存されなかったバグを修正しました。」のように、低レベルの技術的詳細なしで詳細な説明を与えることができます。
于 2009-03-12T12:42:13.100 に答える
1
私の意見では、リリース ノートのベスト プラクティスの 1 つは自動化です。リビジョン管理システムの送信メッセージ ( http://drupal.org/node/52287 )に関する特定のベスト プラクティスがある場合は、自動化されたスクリプト ( http://cvs.drupal.org/viewvc.py/ ) でリリース ノートを作成できます。 drupal/contributions/tricks/cvs-release-notes/ )。これにより、非常に優れたリリース ノートが作成されます: http://drupal.org/node/226165
于 2009-03-12T12:46:34.837 に答える
0
リリース ノートの主な貢献者は開発チームです。開発者とテスターが、TFS の変更セットにリンクされている workItems に対するリリース ノート関連の情報をキャプチャできるようにすることをお勧めします。
次に、 http://tfschangelog.codeplex.comのようなオープン ソース プロジェクトを使用して、リリース ノートを生成できます。GUI バージョンとコマンド ライン バージョンがあり、夜間にリリース ノート レポートを簡単にスケジュールできます。
于 2012-06-05T12:33:43.810 に答える