ChangeLog implementation

[matcra587]

Is your feature request related to a problem? Please describe. The weekly cadence of testnet and mainnet upgrades makes it challenging to keep track of the changes being introduced. Without clear changelogs, it can become difficult to troubleshoot unexpected issues.

For instance, we previously encountered a situation where metrics (in the early days) we were monitoring were changed, and required us to dig through past PRs to understand the cause of the missing data.

- success_metrics
- function_execution_duration_ms
+ river_stream_chain_monitor_head_block
+ river_stream_chain_monitor_processed_block
+ river_stream_chain_monitor_received_events
+ river_stream_dbtx_duration_seconds_bucket
+ river_stream_dbtx_status
+ river_stream_rpc_duration_seconds_bucket
+ river_stream_txpool_pending
+ river_stream_txpool_tx_inclusion_duration_sec_bucket
+ river_stream_txpool_wallet_balance_eth

Another example, the tag comment for testnet/2024-07-29-1 ("Remove needless comment from issue template (#537)") provides little insight into the actual changes included in the release.

Describe the solution you'd like Provide clear and comprehensive changelogs for each weekly testnet and mainnet upgrade. Given the frequency of releases, these changelogs should be concise but informative, including:

Key Changes: A brief summary at the top highlighting the most critical updates. New Features: Short descriptions and usage examples. Removed Features: Clear explanations and alternatives (if applicable). Changes to Existing Features: Concise descriptions of modifications and their rationale. Bug Fixes: Brief summaries of addressed issues. Other Relevant Changes: Important dependency updates, performance enhancements, etc.

The Geth project's release notes serve as an excellent example of how this can be done effectively: https://github.com/ethereum/go-ethereum/releases

Describe alternatives you've considered

• Manually searching through PRs and commits is inefficient and doesn't provide a concise overview.
• River Docs aren't always up to date

Additional context

• Consider using a consistent format for changelogs to facilitate quick scanning.
• Highlight changes that might require action from users (e.g., configuration adjustments).

[shuhuiluo]

Using Conventional Commits should help with automatically generating CHANGELOGs.

[jterzis]

We should strongly consider adding changelog to stream node release process. It would entail changing our commit message, pr title convention. Given that we typically squash commits on merge, we'll need to ensure either the squashed commit message follows a convention amenable to changelog creation or the pr title does. cc @sergekh2 for triage.

[jterzis]

@sergekh2 we need to triage this issue as lack of changelog is posing a risk to network resiliency. Lets triage next meeting.