Release v0.8.0

[guseggert]

Note the releaser and release checker will fail here since the release has already occurred, this is just syncing up main with the release branch.

[codecov]

Codecov Report

Merging #264 (f2bb0c8) into main (085ed9d) will decrease coverage by 0.10%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #264      +/-   ##
==========================================
- Coverage   48.23%   48.14%   -0.10%     
==========================================
  Files         270      270              
  Lines       33064    33064              
==========================================
- Hits        15950    15918      -32     
- Misses      15455    15481      +26     
- Partials     1659     1665       +6     

see 9 files with indirect coverage changes

[aschmahmann]

LGTM (although I haven't read the changelog too closely)

[BigLep]

Great!

My only takeaway from the changelog in this format is that it doesn't necessarily leave me with "why should I care" and "how can I learn more".

Why should I care? - Maybe adding a highlights or tldr section as a place forus to put a bit of commentary. In this particularly release I would want to say things like (quick - off the cuff):

"Library code for HTTP gateways keeps getting better. A major refactor was done to support make requests for blocks rather than individual blocks. This was desired functionality for Kubo and bifrost-gateway."

"We made big steps in Boxo being a capable toolbox for IPFS implementations with getting many repos under one roof so we can avoid version issues between them and apply improvement refactors that were proactively cost-prohibitive before. You can track this effort in #196"

Learn more?
Maybe we just need to add more issue links in the changelog comments. I realize someone can go through gitblame to figure this out if they really want to, but I think it's nice to make it easy. For example, linking to the blockservice/busyloop issue would have helped make it clearer the significance.

[BigLep]

Also, in future, maybe we should have some linking between this PR and #257 and/or some naming conventions to easily differentiate

[guseggert]

Yeah I'm not too fond of the "Keep a Changelog" format TBH, but I can see the value in just using some consistent format that people (and automation) know how to deal with, even if it's not perfect. I don't have a strong opinion either way here.

I would prefer to not have a bunch of prose that ties everything together, just b/c it's a pain to write at release time, I'm really trying to minimize the amount of work it takes to do a release. Maybe we could come up with a format that keeps things discrete but still clearly communicates "motivation" to users?

Issue/PR links sound good.