From 6acf78d42332e703eb112dc8ef7255e6bdc7a13f Mon Sep 17 00:00:00 2001 From: Dana Robinson Date: Fri, 15 Mar 2024 10:33:43 -0700 Subject: [PATCH] Make the newsletter scheme work like HDF4 --- 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 f03f710d717..e69de29bb2d 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 00000000000..f03f710d717 --- /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.