docs: update history related (envoyproxy#21231)

Signed-off-by: Loong Dai <[email protected]>

Author: daixiang0

CONTRIBUTING.md

@@ -109,7 +109,7 @@ versioning guidelines:
   build. If your PR cannot have 100% coverage for some reason please clearly explain why when you
   open it.
 * Any PR that changes user-facing behavior **must** have associated documentation in [docs](docs) as
-  well as [release notes](docs/root/version_history/current.rst). API changes should be documented
+  well as [release notes](changelogs/current.yaml). API changes should be documented
   inline with protos as per the [API contribution guidelines](api/CONTRIBUTING.md). If a change applies
   to multiple sections of the release notes, it should be noted in the first (most important) section
   that applies. For instance, a bug fix that introduces incompatible behavior should be noted in
@@ -150,7 +150,7 @@ versioning guidelines:
   changes for 7 days. Obviously PRs that are closed due to lack of activity can be reopened later.
   Closing stale PRs helps us to keep on top of all of the work currently in flight.
 * If a commit deprecates a feature, the commit message must mention what has been deprecated.
-  Additionally, the [version history](docs/root/version_history/current.rst) must be updated with
+  Additionally, the [version history](changelogs/current.yaml) must be updated with
   relevant RST links for fields and messages as part of the commit.
 * Please consider joining the [envoy-dev](https://groups.google.com/forum/#!forum/envoy-dev)
   mailing list.
@@ -219,11 +219,12 @@ Runtime code is held to the same standard as regular Envoy code, so both the old
 path and the new should have 100% coverage both with the feature defaulting true
 and false.
 
-Please note that if adding a runtime guarded feature, your [release notes](docs/root/version_history/current.rst) should include both the functional change, and how to revert it, for example
+Please note that if adding a runtime guarded feature, your [release notes](changelogs/current.yaml) should include both the functional change, and how to revert it, for example
 
-```rst
-* http: changed the ``:scheme`` header to ``:schema``. This behavioral change can be
-temporarily reverted by setting runtime guard ``envoy.reloadable_features.schema_is_better_than_scheme`` to false.
+```yaml
+- area: config
+  change: |
+      type URL is used to lookup extensions regardless of the name field. This may cause problems for empty filter configurations or mis-matched protobuf as the typed configurations. This behavioral change can be temporarily reverted by setting runtime guard ``envoy.reloadable_features.no_extension_lookup_by_name`` to false.
 ```
 
 # PR review policy for maintainers

PULL_REQUESTS.md

@@ -65,7 +65,7 @@ Request](https://www.envoyproxy.io/docs/envoy/latest/intro/life_of_a_request) do
 ### <a name="relnotes"></a>Release notes
 
 If this change is user impacting OR extension developer impacting (filter API, etc.) you **must**
-add a release note to the [version history](docs/root/version_history/current.rst) for the
+add a release note to the [version history](changelogs/current.yaml) for the
 current version. Please include any relevant links. Each release note should be prefixed with the
 relevant subsystem in **alphabetical order** (see existing examples as a guide) and include links
 to relevant parts of the documentation. Thank you! Please write in N/A if there are no release notes.
@@ -118,7 +118,7 @@ merged.
 ### <a name="deprecated"></a>Deprecated
 
 If this PR deprecates existing Envoy APIs or code, it should include an update to the deprecated
-section of the [version history](docs/root/version_history/current.rst) and a one line note in the
+section of the [version history](changelogs/current.yaml) and a one line note in the
 PR description.
 
 If you mark existing APIs or code as deprecated, when the next release is cut, the

RELEASES.md

@@ -100,12 +100,12 @@ deadline of 3 weeks.
 * Begin marshalling the ongoing PR flow in this repo. Ask maintainers to hold off merging any
   particularly risky PRs until after the release is tagged. This is because we aim for main to be
   at release candidate quality at all times.
-* Do a final check of the [release notes](docs/root/version_history/current.rst):
+* Do a final check of the [release notes](changelogs/current.yaml):
   * Make any needed corrections (grammar, punctuation, formatting, etc.).
   * Check to see if any security/stable version release notes are duplicated in
     the major version release notes. These should not be duplicated.
   * If the "Deprecated" section is empty, delete it.
-  * Remove the "Pending" tags and add dates to the top of the [release notes for this version](docs/root/version_history/current.rst).
+  * Remove the "Pending" tags and add dates to the top of the [release notes for this version](changelogs/current.yaml).
   * Switch the [VERSION.txt](VERSION.txt) from a "dev" variant to a final variant. E.g., "1.6.0-dev" to
     "1.6.0".
   * Update the [RELEASES](RELEASES.md) doc with the relevant dates. Now, or after you cut the
@@ -129,45 +129,37 @@ deadline of 3 weeks.
   post.
 * Do a new PR to setup the next version
   * Update [VERSION.txt](VERSION.txt) to the next development release. E.g., "1.7.0-dev".
-  * `git mv docs/root/version_history/current.rst docs/root/version_history/v1.6.0.rst`, filling in the previous
+  * `git mv changelogs/current.yaml changelogs/1.6.0.yaml`, filling in the previous
     release version number in the filename and delete empty sections (like Incompatible Behavior Changes, Minor Bahavior Changes, etc).
     Add an entry for the new file in the `toctree` in
     [version_history.rst](docs/root/version_history/version_history.rst).
   * Edit the file you just created (eg `docs/root/version_history/v1.6.0.rst`) replacing the link part (between the `<>`) of any `ref:` links to point at the version - eg `` :ref:`Some link text <actual link>` `` -> `` :ref:`Some link text <v1.16:actual link>` ``
   * Create a new "current" version history file at the [release
-  notes](docs/root/version_history/current.rst) for the following version. E.g., "1.7.0 (pending)". Use
+  notes](changelogs/current.yaml) for the following version. E.g., "1.7.0 (pending)". Use
   this text as the template for the new file:
-```
-1.7.0 (Pending)
-===============
+```yaml
+date: Pending
+behavior_changes:
+# Changes that are expected to cause an incompatibility if applicable; deployment changes are likely required
 
-Incompatible Behavior Changes
------------------------------
-*Changes that are expected to cause an incompatibility if applicable; deployment changes are likely required*
+minor_behavior_changes:
+# Changes that may cause incompatibilities for some users, but should not for most*
 
-Minor Behavior Changes
-----------------------
-*Changes that may cause incompatibilities for some users, but should not for most*
+bug_fixes:
+# Changes expected to improve the state of the world and are unlikely to have negative effects*
 
-Bug Fixes
----------
-*Changes expected to improve the state of the world and are unlikely to have negative effects*
+removed_config_or_runtime:
+# Normally occurs at the end of the* :ref:`deprecation period <deprecated>`
 
-Removed Config or Runtime
--------------------------
-*Normally occurs at the end of the* :ref:`deprecation period <deprecated>`
+new_features:
 
-New Features
-------------
+deprecated:
 
-Deprecated
-----------
+# Run the deprecate_versions.py script (e.g. `bazel run //tools/deprecate_version:deprecate_version`)
+#  to file tracking issues for runtime guarded code which can be removed.
+# Check source/common/runtime/runtime_features.cc and see if any runtime guards in
+# disabled_runtime_features should be reassessed, and ping on the relevant issues.
 ```
-* Run the deprecate_versions.py script (e.g. `bazel run //tools/deprecate_version:deprecate_version`)
-  to file tracking issues for runtime guarded code which can be removed.
-* Check source/common/runtime/runtime_features.cc and see if any runtime guards in
-  disabled_runtime_features should be reassessed, and ping on the relevant issues.
-
 
 ## Security release schedule