Document the release process

[BigLep]

Done Criteria

It's clear for an outsider to understand:

1. How often we release
2. How they can track a release's progress
3. The steps of a release
4. Release owner

Why Important

"Clear is kind." This sets clear expectations for current and potential consumers. It also makes it clear for current/future maintainers on what is expected.

Notes

I expect work involved here will include:

1. README update
2. Release template md file we copy into each release issue
3. Changelog md files

Given the main maintainers of this project are the Kubo maintainers and a major production consumer of this library is Kubo, I assume we'll have it follow the Kubo release cadence where we'd cut a new go-libipfs release shortly before a new Kubo RC.

[BigLep]

2023-03-07 conversation:
Likely have steps around bubbling up to Kubo and Lotus for sanity checking.

[guseggert]

I'd vote for cutting releases with Kubo, at the same time. Given the same folks maintain Kubo and go-libipfs, I think using the Kubo release + testing process to additionally test go-libipfs should be fine and will make go-libipfs releases more solid.

So then the release process would be to e.g. cut go-libipfs RC1 and use it in Kubo RC1, and then Kubo final release depends on the go-libipfs final release.

[BigLep]

@guseggert : per verbal conversation, our changelog process is very important for this one. I believe rust-libp2p and now ipfs gateway conformance tests (ipfs/gateway-conformance#19 ) have mechanisms for actually driving releases from changelog (which puts emphasis on stewarding the changelog - good I think). Just passing on as something to consider.

[guseggert]

Initial pass at documenting the release process: #266

Based on the process I followed for releasing v0.8.0

[guseggert]

@guseggert : per verbal conversation, our changelog process is very important for this one. I believe rust-libp2p and now ipfs gateway conformance tests (ipfs/gateway-conformance#19 ) have mechanisms for actually driving releases from changelog (which puts emphasis on stewarding the changelog - good I think). Just passing on as something to consider.

For driving releases from changelog, I have opened #269 with details and done criteria. We need some more work on tooling to get this over the line.

[guseggert]

See https://github.com/ipfs/boxo/blob/main/RELEASE.md