From 26837b4af843eefd8f867091482dd222ebf698e2 Mon Sep 17 00:00:00 2001 From: Dana Robinson <43805+derobins@users.noreply.github.com> Date: Fri, 15 Mar 2024 10:36:18 -0700 Subject: Make the newsletter scheme work like HDF4 (#4149) --- release_docs/NEWSLETTER.txt | 25 ------------------------- release_docs/NEWSLETTER_README.txt | 25 +++++++++++++++++++++++++ 2 files changed, 25 insertions(+), 25 deletions(-) create mode 100644 release_docs/NEWSLETTER_README.txt diff --git a/release_docs/NEWSLETTER.txt b/release_docs/NEWSLETTER.txt index f03f710..e69de29 100644 --- a/release_docs/NEWSLETTER.txt +++ b/release_docs/NEWSLETTER.txt @@ -1,25 +0,0 @@ -INTRODUCTION -============ - -This purpose of this document is to contain entries that can be used to quickly -produce a release newsletter. When something is added to the library that is -"newsletter worthy" (i.e., new feature, CVE fix, etc.) a summary note should -be added here. - -The format should look like this: - -* SUMMARY OF NEWSLETTER-WORTHY THING - - Here is where you describe the summary. Summarize the feature, fix, or - change in general language. Remember, RELEASE.txt is for communicating - technical specifics. Text entered here is more like advertising. - - (GitHub #123, #125) - -The GitHub #s could be relevant issues or PRs. They will probably not appear -in the final newsletter, but are so that the person writing the newsletter -has easy access to context if they have questions. - -Every entry in RELEASE.txt does NOT require an entry here. The newsletter is -for communicating major changes that are of interest to anyone. Minor bugfixes, -memory leak fixes, etc. do not require entries. diff --git a/release_docs/NEWSLETTER_README.txt b/release_docs/NEWSLETTER_README.txt new file mode 100644 index 0000000..f03f710 --- /dev/null +++ b/release_docs/NEWSLETTER_README.txt @@ -0,0 +1,25 @@ +INTRODUCTION +============ + +This purpose of this document is to contain entries that can be used to quickly +produce a release newsletter. When something is added to the library that is +"newsletter worthy" (i.e., new feature, CVE fix, etc.) a summary note should +be added here. + +The format should look like this: + +* SUMMARY OF NEWSLETTER-WORTHY THING + + Here is where you describe the summary. Summarize the feature, fix, or + change in general language. Remember, RELEASE.txt is for communicating + technical specifics. Text entered here is more like advertising. + + (GitHub #123, #125) + +The GitHub #s could be relevant issues or PRs. They will probably not appear +in the final newsletter, but are so that the person writing the newsletter +has easy access to context if they have questions. + +Every entry in RELEASE.txt does NOT require an entry here. The newsletter is +for communicating major changes that are of interest to anyone. Minor bugfixes, +memory leak fixes, etc. do not require entries. -- cgit v0.12