A few notes:

The version is mentioned only once, at the top
Changes are grouped by patch|minor|major
Empty groups can be hidden (like major, in the example below)
For each commit, there's a list of the packages affected by it

Release - 0.43.1

Patch:

Support EVM Address type, by @danielbate (See #995)
- @fuel-ts/address
- @fuel-ts/interfaces
- @fuel-ts/abi-coder
Another Patch Message.. @arboleya (See #NNN)
- @fuel-ts/abc
- @fuel-ts/xyz

Minor:

Something else.. @Dhaiwat10 (See #NNN)
- @fuel-ts/xyz

Breaking Changes:

Something else.. @Dhaiwat10 (See #NNN)
- @fuel-ts/xyz

Here we'd repeat only the breaking ones.

Originally posted by @arboleya in https://github.com/FuelLabs/fuels-ts/issues/1022#issuecomment-1567505857

May 30 '23 10:05 arboleya

I'll take care of this along with #970

Jun 01 '23 18:06 Dhaiwat10

https://github.com/FuelLabs/fuels-ts/issues/1347

Dec 11 '23 11:12 arboleya

We really need to devise a solution to these noisy changelogs.

Feb 05 '24 16:02 arboleya

https://github.com/FuelLabs/fuels-ts/issues/970

Feb 05 '24 16:02 arboleya

Here's a bit of a different take but in the same spirit of reducing noise:

There are no groupings by patch|minor|major because the title of the changelog already contains what type of update it is (RELEASE - 0.77.0 is a minor update),
All the affected packages of the release are listed once under the title for completion's sake,
Changes are grouped into breaking and non-breaking and each change is shown only once,
Changes are sub-grouped into features, fixes, refactors, chores, and docs,
Breaking changes are formatted the same way as non-breaking changes,
The affected packages are put into a one-liner instead of a bullet point list (looks less cluttered)

Also note that I didn't format the changes as bullet points. That is because the changeset's description can have bullet points themselves, be multiline, etc. All of its formatting would be affected by a bullet point dash before it.

RELEASE - 0.77.0

fuels, @fuel-ts/abi-coder, @fuel-ts/account, @fuel-ts/address, @fuel-ts/contract, @fuel-ts/crypto, @fuel-ts/errors, @fuel-ts/hasher, @fuel-ts/merkle, @fuel-ts/transactions

Breaking Changes

Yay, no breaking changes!

Non-breaking Changes

Features

Added requestMiddleware to ProviderOptions as a way to allow the user the modification of each fetch call's request, by @nedsalk (see #1822) (packages: @fuel-ts/account)

Fixes

Handling SqueezedOut status update when calling submitAndAwait subscription at Provider.sendTransaction
Handling SqueezedOut status update when calling statusChange subscrition at TransactionResponse.waitForResult, by @Torres-ssf (see #1829) (packages: @fuel-ts/account, @fuel-ts/errors)

fix: disallow transferring <= 0 amounts, by @Dhaiwat10 (see #1827) (packages: @fuel-ts/account, @fuel-ts/errors)

Chores

Migrate implementations of sha256, keccak and scrypt to @noble/hashes, by @danielbate (see #1786) (packages: @fuel-ts/abi-coder, @fuel-ts/account, @fuel-ts/address, @fuel-ts/contract, @fuel-ts/crypto, @fuel-ts/errors, @fuel-ts/hasher, @fuel-ts/merkle, @fuel-ts/transactions)

Add try/catch block when parsing GraphQL stream data response, by @Torres-ssf (see #1839) (packages: @fuel-ts/account, @fuel-ts/errors)

Mar 12 '24 06:03 nedsalk

I liked the new grouping. 👌

But let's try to reduce noise even more.

A few assumptions:

PR titles should be short and sweet
Changesets must follow the PR title (and nothing else 👈 )
PR Descriptions may contain, in this order:
1. The issue it is closing
2. Breaking change notes
3. Summary, notes, details, etc.

See:

PR example below, inspired by #1826
Changelog example in the next comment

Close #1506

Breaking

// old API
const predicate = new Predicate(bytecode, provider, abi, configurableConstants);

// new API
const predicate = new Predicate({
  bytecode,
  abi, // optional
  provider,
  inputData, // optional
  configurableConstants, // optional
});

Summary

Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Mar 15 '24 13:03 arboleya

Release - 0.43.1

Breaking

Features
- #1356 Add launchTestNode utility, by @nedsalk
- #1826 Improve Predicate DX; accepting data in the constructor, by @Dhaiwat10
Fixes
- #1787 Assemble of Transfer operation, by @Torres-ssf
Chores
- #1877 Exporting Asset types, by @Torres

Features

#995 Support EvmAddress, by @danielbate
#1864 Add local faucet for the create-fuels app, by @Dhaiwat10
#1864 Added new Date wrapper, by @petertonysmith94

Fixes

#1847 Handling empty changesets in release4 workflow, by @nedsalk

Mar 15 '24 13:03 arboleya

https://github.com/FuelLabs/fuels-ts/issues/1028#issuecomment-1999723460

This decreases the noise massively and better summarises the release into a small digest.

Is it worth adding all the affected packages for the release as a whole? Like @nedsalk had here.

Release - 0.43.1

fuels, @fuel-ts/abi-coder, @fuel-ts/account, @fuel-ts/address, @fuel-ts/contract, @fuel-ts/crypto, @fuel-ts/errors, @fuel-ts/hasher, @fuel-ts/merkle, @fuel-ts/transactions ... ...

Mar 15 '24 14:03 petertonysmith94

Release - 0.43.1

Breaking

Features:

#1356 Add launchTestNode utility, by @nedsalk

#1826 Improve Predicate DX; accepting data in the constructor, ...

I really liked this proposed version. It's very clean and easy to read

Mar 15 '24 14:03 Torres-ssf

@petertonysmith94 I don't think we should list the affected packages in the release notes.

We bump all packages together on each release anyway; it's like everything changed.

However, each package will still have its changelog file.

Mar 15 '24 14:03 arboleya

@arboleya All very valid points. I retract my previous suggestion.

Mar 15 '24 15:03 petertonysmith94

We can differentiate between breaking and non-breaking changes with $\color{red}{\bf{(!)}}$, put the breaking changes first and simplify it further: