[repo] introduce NEXT_RELEASE_NOTES to aggregate release notes for the next release

NEXT_RELEASE_NOTES.md

@@ -0,0 +1,42 @@
+# Upcoming Release Notes
+
+## About & Process
+
+This file aggregates the changes and updates that will be included in the next release notes.
+
+Its goal is to facilitate the process of writing release notes, as well as making it easier to use this repository from its `main` branch.
+
+Pull requests that introduce major changes, especially breaking changes to configurations, or otherwise important new features, should update this file
+with the details necessary for users to migrate and fully use any added functionality.
+
+At the time of release, the content below the horizontal line in this file will be copied to the release notes and deleted from this file.
+
+### Template & Examples
+
+The release notes should contain at least the following sections:
+
+#### Mandatory migration tasks
+
+* Rename uss_qualifier ABCScenario in test configurations/suites to XYZScenario
+    * Note that XYZScenario is currently skipped in most sample and development configurations.
+* Rename uss_qualifier resource in test configurations/suites:
+    * resources.a.b.ABCResource -> resources.x.y.XYResource
+
+#### Optional migration tasks
+
+* Rename uss_qualifier resource resources.x.y.z.SomeResource -> resources.SomeResource
+    * For compatibility, the old name is currently an alias to the new name (this use produces a deprecation warning), but support for the old name will be removed in a future version.
+
+#### Important information
+
+* Feature X has changed behavior to Y
+
+--------------------------------------------------------------------------------------------------------------------
+
+# Release Notes for v0.17.0
+
+## Mandatory migration tasks
+
+## Optional migration tasks
+
+## Important information

RELEASE.md

@@ -2,6 +2,8 @@
 
 Releases of monitoring are based on git tags in the format `interuss/monitoring/v[0-9]+\.[0-9]+\.[0-9]+`, optionally suffixed with `-[0-9A-Za-z-.]+`.  This tag form follows the pattern `[owner]/[component]/[semantic version]`; see [semantic version](https://semver.org) for more information.
 
+Keeping track of breaking changes and migration instructions is done through the [NEXT_RELEASE_NOTES.md](NEXT_RELEASE_NOTES.md) file, which is updated as features are added or modified and serves as a basis for release notes.
+
 When either an executable or image is built from a `git` checkout of the source, the most recent tag is used as the version tag. If no such tag exists, the build system defaults to v0.0.0-[commit_hash]. If commits have been added to the tag, the commit hash is appended to the version. If the workspace is not clean, `-dirty` is appended to it. The version tag is computed by [`scripts/git/version.sh`](scripts/git/version.sh).
 
 Releasing a monitoring version requires the following steps:
@@ -15,6 +17,8 @@ Releasing a monitoring version requires the following steps:
         - Note that valid examples of this form include `0.1.0`, `20.0.0`, `0.5.0-rc`, `0.5.0-1.2`
     - Official releases are `interuss/monitoring/v#.#.#`.
 - The github workflow ([.github/workflows/image-publish.yml](.github/workflows/image-publish.yml)) is triggered for every new release tag. On the canonical interuss fork, it builds and publishes the monitoring image to the [official docker registry](https://hub.docker.com/repository/docker/interuss/monitoring).
+- Add the pending release notes from [NEXT_RELEASE_NOTES.md](NEXT_RELEASE_NOTES.md) to the release notes.
+- After completing the release, open a PR to remove the pending release notes from [NEXT_RELEASE_NOTES.md](NEXT_RELEASE_NOTES.md)
 
 To enable releases of monitoring version in a fork, the following steps are required:
   1. Set the remote origin url of the repository of the target fork. (ie git@github.com:[owner]/monitoring.git)