[al_borland]

As a user, I like release notes that tell me new features exists that I can explore, and/or tell me which user-facing bugs were fixed, so I can try using the feature again that I’ve been avoiding.

What I absolutely hate is the generic release note that seemed to come about with agile release schedules. Notes like, “bug fixes and performance improvements”, “Thanks for using <app_name>, we make regular improvements to ensure your experience is top notch”, or “We update our app often to <insert_marketing_taglines>.”

This tells me nothing and makes me less likely to bother reading any release notes at all.

[beratbozkurt0]

I absolutely agree, and I really enjoy it when they show me what new things I can do with this change and how I can do them. Lately, Dia browser and raycast handle this nicely. I think most companies should base their strategies on this.

This will keep existing users on the app for longer. If you're a project manager or manage an app, this is definitely something you should care about.

Also, I'm trying something out here because I saw a loophole, let's see how it goes :)

[JohnFen]

I couldn't agree more. Release notes like that are informationally identical to a release note that just says "New release."

I use release notes to help me decide whether not to update to the new release. I would prefer that no release note is made at all over that kind of thing. At least that's being honest about not wanting to say what the changes were.

[beratbozkurt0]

But what if that release really only included bug fixes and speed improvements?

[al_borland]

What bugs were fixed? What was made faster? If I was experiencing some bugs or slowness, I would be happy to see my issue may have been addressed in the release. If it says the issue was fixed, and I still see an issue, that’s a reason to send some feedback again.