Starting with the v0.52 release, I'd like us to write short-ish blog-posts walking through some of the new features / changes of releases, especially ones with breaking changes.

I'd like to push back against this. I don't think publishing a blog post for releases makes a lot of sense. It's unfortunate that I'm now the guy advocating for letting the work spent on this PR to go to waste. I wish this proposal would have been raised and discussed before investing time into actually writing a blog post.

First of all, having rust-libp2p post release notes effectively requires other language implementations to do the same. This is additional work that would be better spent on engineering.

Publishing blog post would be the 3rd place where we post what is effectively release notes:

1. The GitHub release.
2. Discourse.
3. The blog.

We've been trying to make releases low-overhead, and writing blog posts about every release seems to achieve the opposite of this.

It also creates a lot of noise if we do this for every language. Having people subscribe to GitHub notifications for new releases seems to be the strictly better way to achieve the goal of informing users about new releases (you can subscribe to notifications for the one implementation you care about).

This doesn't preclude us from writing blog posts about new exciting features we roll out (and mentioning the release in which it was rolled). That's what we should do! It makes a lot more sense to be focus on the new feature, and why we think that feature is a value-add for libp2p users, instead of burying it in a copy-paste of release notes.

Example for this: We should have a blog post highlighting the metrics that go-libp2p now offers. This is a better way to present the information than having a section about that in a hypothetic "What's new in go-libp2p v0.28" blog post.

I wish this proposal would have been raised and discussed before investing time into actually writing a blog post.

It was raised and discussed with @dhuseby and @mxinden.

First of all, having rust-libp2p post release notes effectively requires other language implementations to do the same.

Why? I disagree. The rust-libp2p team has not posted in the forum about releases for a while. I was today years old that I learned that this is actually a thing or that other implementations do that.

I see the different implementations as separate communities that all work together because we follow the same spec. Just because one team wants to write release blogposts doesn't mean the others have to follow suit. How would that even work for community-developed implementations or ones sponsored by other companies?

GitHub notifications for new releases seems to be the strictly better way

It is not. I'd rather post a blogpost to a newsletter like This-Week-In-Rust and not the link to a GitHub release. Plus, I don't know how well search-indexed they are but I'd guess that a static webpage is easier to find than GitHub's releases and thus drives more traffic.

Example for this: We should have a blog post highlighting the metrics that go-libp2p now offers. This is a better way to present the information than having a section about that in a hypothetic "What's new in go-libp2p v0.28" blog post.

Which one is "better" seems to be only a matter of taste here. For practical reasons, it makes sense to batch breaking changes together which means that one release is likely to contain several features that are worth talking about. Writing a post about each one of them would create a lot of noise.

For example, I enjoy skimming and reading through the bevy release blogposts: https://bevyengine.org/news/bevy-0-10/
I don't use the library myself but they do some really cool advanced Rust which is interesting to learn about. I imagine there are other people like that there that would enjoy reading what is happening in the (rust)-libp2p space without having to subscribe to GitHub releases.

Our cadence of breaking releases is about 3 months. That is hardly worth mentioning both in terms of effort and "noise" on the blog.

If you feel strongly @marten-seemann, I'll just post these as our release notes on the GitHub release. I still believe that a blogpost would give better visibility but it is ultimately not worth the friction of discussing it if we have an alternative.

I see the different implementations as separate communities that all work together because we follow the same spec. Just because one team wants to write release blogposts doesn't mean the others have to follow suit. How would that even work for community-developed implementations or ones sponsored by other companies?

I don't think it's as easy as this, at least for PL-maintained implementations. Otherwise, readers will ask "why is rust-libp2p releasing and js-libp2p / go-libp2p aren't?". We should have a minimum amount of consistency here.

Our cadence of breaking releases is about 3 months. That is hardly worth mentioning both in terms of effort and "noise" on the blog.

go-libp2p has released every other month, and we just decided to release more frequently, because releases are not expensive. Publishing blog posts would drive up the cost.

Plus, I don't know how well search-indexed they are but I'd guess that a static webpage is easier to find than GitHub's releases and thus drives more traffic.

Searching for "libp2p smart dialing" already links to the go-libp2p release page in the 2nd search result (the first is the issue with the same name). I don't understand why github.com would be penalized by Google's search algorithm. This will be hard to argue one side or the other though, given that we don't have insight into Google's algorithm.

For practical reasons, it makes sense to batch breaking changes together which means that one release is likely to contain several features that are worth talking about. Writing a post about each one of them would create a lot of noise.

Having a blog post that explains a cool new feature that we put a lot of thought in and that we think drastically improves performance / user experience of a libp2p stack is the opposite of noise.
On the other hand, it's much harder for the reader to tell if a blog post named "xxx-libp2p vX.Y.Z release" will contain anything of interest.

I imagine there are other people like that there that would enjoy reading what is happening in the (rust)-libp2p space without having to subscribe to GitHub releases.

I didn't say we shouldn't post about rust-libp2p. Quite the opposite. The only disagreement is the format of these posts ("release vX.Y.Z") vs. "cool new libp2p feature".

Our cadence of breaking releases is about 3 months. That is hardly worth mentioning both in terms of effort and "noise" on the blog.

go-libp2p has released every other month, and we just decided to release more frequently, because releases are not expensive. Publishing blog posts would drive up the cost.

I was explicitly talking about releases with breaking changes (which would get one of these posts). We've made multiple patch releases per week before that.

Replaced with release notes.

@thomaseizinger 's original plan was to do a video walkthrough of the changes in 0.52.0 1st slack thread
And I chimed in to say if we have a video we should accompany it with a blog

Thomas: The next release contains so many exciting things though that I am thinking of creating a short walk-through video!

Prithvi: poking in here to say that sounds awesome, if you decide to do this maybe with some accompanying text we can post it on the blog?

video + blog was also mentioned here 2nd slack thread
It looks like the video idea has been scrapped and without a it, the blog does read more like a Changelog. So I get the hesitation around merging this PR.¹

However, I still think we should publish this after editorializing a bit. This post is about the culmination of work in rust-libp2p since February, there are many big things to highlight but maybe not each one can stand on it's own leg as a longer post.
Therefore, my suggestion would be to reframe this as not strictly a blog post about the 0.52.0 but rust-libp2p in the last 6 months i.e. "Big QoL changes in the latest rust-libp2p"
I can help editorialize it to some extent.
Also if the cadence of breaking change releases in rust-libp2p is every 3 months, I think it's fine to have a blog to accompany them. As long as it's not presented as just a changelog and editorialized a bit more nicely.

I'm thinking of doing the same thing for js-libp2p #83 either as a standalone blog or a part of #81

So would folks be open with reopening this PR, changing the blog title to something more generic i.e. "Big QoL changes in the latest rust-libp2p" or "rust-libp2p in the 1st half of 2023", editorializing it a bit, and posting? I am in favor of this

Another thought - perhaps it's worth pulling in the content in 0.51.0 i.e. around the NetworkBehavior changes, i.e what motivated them and technical details

My 2p on this is:

• blog posts about releases is really only useful if it gives more context than a bullet list of changes
• we already want to be doing technical deep dive blog posts at least once per quarter but ideally once per month
• why don't we combine the two so that we do technical deep dive blog posts on a regular cadence that highlights something new in one of the latest releases and then at the bottom have a conclusion that briefly covers the other stuff in the release notes.
• we wouldn't do a blog post for every release, we'd keep release notes, but we'd do these blog posts on a regular cadence.

@thomaseizinger 's original plan was to do a video walkthrough of the changes in 0.52.0 1st slack thread
And I chimed in to say if we have a video we should accompany it with a blog

Thomas: The next release contains so many exciting things though that I am thinking of creating a short walk-through video!

Prithvi: poking in here to say that sounds awesome, if you decide to do this maybe with some accompanying text we can post it on the blog?

video + blog was also mentioned here 2nd slack thread
It looks like the video idea has been scrapped and without a it, the blog does read more like a Changelog.

Yeah I ended up not having the time for it and we wanted to get the release out.

So would folks be open with reopening this PR, changing the blog title to something more generic i.e. "Big QoL changes in the latest rust-libp2p" or "rust-libp2p in the 1st half of 2023", editorializing it a bit, and posting? I am in favor of this

This post is now within the GitHub release notes which also has been posted to This-Week-In-Rust. I don't think we need to post it separately.

• we already want to be doing technical deep dive blog posts at least once per quarter but ideally once per month

Is this per language or in general?

• why don't we combine the two so that we do technical deep dive blog posts on a regular cadence that highlights something new in one of the latest releases and then at the bottom have a conclusion that briefly covers the other stuff in the release notes.

I've accustomed to the idea what we should just write more exhaustive release notes so I think focussing on a particular feature or technical design per blogpost is good.