evergreen-docs:release_notes_process
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
evergreen-docs:release_notes_process [2018/09/06 14:19] – sandbergja | evergreen-docs:release_notes_process [2023/06/01 12:00] – update branch name from master to main gmcharlton | ||
---|---|---|---|
Line 3: | Line 3: | ||
====Major Release Notes==== | ====Major Release Notes==== | ||
+ | |||
+ | => See also the [[dev: | ||
===Preparing for the release=== | ===Preparing for the release=== | ||
- | Before the beta is cut, periodically review [[https:// | + | Before the beta is cut, periodically review [[https:// |
===Generating the release notes file=== | ===Generating the release notes file=== | ||
Line 21: | Line 23: | ||
* For **individuals who contributed code, management, translations, | * For **individuals who contributed code, management, translations, | ||
* Acknowledge the code contributors who authored any portion of the **new features** that are listed in the release notes. By focusing on new features, we are omitting many code contributions made to that particular branch that were bug fixes. The reason for this omission is that, since those branches were backported, those contributors were already acknowledged in the monthly point release notes for other releases. | * Acknowledge the code contributors who authored any portion of the **new features** that are listed in the release notes. By focusing on new features, we are omitting many code contributions made to that particular branch that were bug fixes. The reason for this omission is that, since those branches were backported, those contributors were already acknowledged in the monthly point release notes for other releases. | ||
- | * One workflow to get this information: | + | * One workflow to get this information: |
+ | * Use the list of new features to identify | ||
+ | * For each launchpad bug ID, search | ||
+ | * Note the people who authored and signed off on each relevant commit. | ||
* Acknowledge contributors responsible for managing or building the release. | * Acknowledge contributors responsible for managing or building the release. | ||
* Acknowledge translators who added translations for one of the ' | * Acknowledge translators who added translations for one of the ' | ||
* Acknowledge documenters who have contributed documentations for new features in this release. As is the case with code contributors, | * Acknowledge documenters who have contributed documentations for new features in this release. As is the case with code contributors, | ||
- | * Acknowledge authors of any tests that were written for that release. Tests are most often written with the code for a new feature or a bug fix. However, when a test is written apart from any new feature or bug fix, those tests are typically merged to the master | + | * Acknowledge authors of any tests that were written for that release. Tests are most often written with the code for a new feature or a bug fix. However, when a test is written apart from any new feature or bug fix, those tests are typically merged to the main branch and not backported. Therefore, those authors should be acknowledged in the major release notes. |
- | * For **organizations whose employees contributed patches**, identify the library institutions, | + | * For **organizations whose employees contributed patches**, identify the library institutions, |
Line 33: | Line 38: | ||
==List of bug fixes== | ==List of bug fixes== | ||
- Go through the git commits for each release branch (e.g. rel_17_9 and rel_17_10) to find which bugs have been fixed since the last release. It's easier to start with the earliest branch (e.g. rel_17_9). | - Go through the git commits for each release branch (e.g. rel_17_9 and rel_17_10) to find which bugs have been fixed since the last release. It's easier to start with the earliest branch (e.g. rel_17_9). | ||
- | - Add a complete list of bug fixes to the top of the appropriate release notes file (e.g. RELEASE_NOTES_7_9.adoc) using Asciidoc. | + | - Add a complete list of bug fixes to the top of the appropriate release notes file (e.g. RELEASE_NOTES_17_9.adoc) using Asciidoc. |
- | - Commit your changes with a commit message like "Docs: Release notes for Evergreen 17.9.3" | + | - Commit your changes with a commit message like "Docs: Release notes for Evergreen 17.9.3" |
- Repeat the process for each other relevant release. | - Repeat the process for each other relevant release. | ||
- Push the commits to the release notes to the following branches: | - Push the commits to the release notes to the following branches: | ||
- | * master | + | * main |
* the newer major release branch (e.g. rel_17_10) | * the newer major release branch (e.g. rel_17_10) | ||
* the older major release branch, but only include the changes to the earlier branch (e.g. don't put the 17.10 changes in the rel_17_9 branch). | * the older major release branch, but only include the changes to the earlier branch (e.g. don't put the 17.10 changes in the rel_17_9 branch). | ||
Line 45: | Line 50: | ||
Acknowledgements for point release notes have varied, but current practice has been to acknowledge the contributors, | Acknowledgements for point release notes have varied, but current practice has been to acknowledge the contributors, | ||
- | | + | |
+ | * You could use git to find all the authors/ | ||
+ | * '' | ||
+ | * If you want to limit it to authors and committers, try the following: | ||
+ | * '' | ||
+ | * '' | ||
+ | * '' |
evergreen-docs/release_notes_process.txt · Last modified: 2024/02/12 15:55 by stompro