docs: release notes template

[mpoke]

Description

Closes: NA

Add template for release notes and upgrading info.

---

Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

• included the correct docs: prefix in the PR title
• targeted the correct branch (see PR Targeting)
• provided a link to the relevant issue or specification
• reviewed "Files changed" and left comments if necessary
• confirmed all CI checks have passed

Reviewers Checklist

All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.

I have...

• Confirmed the correct docs: prefix in the PR title
• Confirmed all author checklist items have been addressed
• Confirmed that this PR only changes documentation
• Reviewed content for consistency
• Reviewed content for spelling and grammar
• Tested instructions (if applicable)
• Checked that the documentation website can be built and deployed successfully (run make build-docs)

[mpoke]

This should do the trick.

[shaspitz]

I understand that everyone should be pro-documentation. But we should be careful not to introduce extraneous documentation and processes that slow people down, or just make things hard to find. Staying lean is still important and there's a balance to be struck.

For example I think the info in UPGRADING.md could be included in existing docs like the changelog or release notes.

[shaspitz]

Shouldn't this link to https://github.com/cosmos/interchain-security/tree/release/v3.0.x?

[mpoke]

No. It should be https://github.com/cosmos/interchain-security/releases/tag/v3.0.0 once we cut v3.0.0. In the meantime, it's good to point to the release candidate.

[shaspitz]

Maybe change the text from v3.0.x to v3.0.0 then, but not a biggie

[shaspitz]

Is the idea that we'd copy/paste this into a release description, or does GH handle the template automatically?

[mpoke]

Once we add goreleaser to this repo, this file will act as input. See the release process on Gaia for more details https://github.com/cosmos/gaia/blob/main/RELEASE_PROCESS.md#release-notes

[mpoke]

I understand that everyone should be pro-documentation. But we should be careful not to introduce extraneous documentation and processes that slow people down, or just make things hard to find. Staying lean is still important and there's a balance to be struck.

For example I think the info in UPGRADING.md could be included in existing docs like the changelog or release notes.

Thanks for the feedback @smarshall-spitzbart. The reason for this PR is to standardize our release process. Since the SDK repo is using this approach, I think it makes sense for the ICS repo to also adopt it. Note that the Gaia repo will also use this starting with v11.

Benefits of this approach:

• More concise release notes with clear links for different stakeholders. See https://github.com/cosmos/interchain-security/releases/tag/v3.0.0-rc0 vs. https://github.com/cosmos/interchain-security/releases/tag/v2.0.0.
• Consistent structure for the ICS releases. Currently, it's difficult to find the needed info to use ICS (is it in the release notes, the changelog, or in the documentation).

[shaspitz]

@mpoke all fair stuff, I agree with the benefits of this approach 👍. I think the info from UPGRADING.md is useful, but would be better in the RELEASE_NOTES.md to reduce the amount of mds we have to maintain