Changelog confusion regarding Edit functionality

[benjaoming]

Bug Description

Well first of all, thanks for keeping a changelog. That's always nice :+1:

The changelog indicates that the edit functionality was introduced somehow in both 6.33 and 6.34. But I can de-facto already use it in 6.32?

6.34:

Now you can right-click on any sent message or press the up arrow on your keyboard to edit what you just said! Fix a tpyo, include the missing ingredient in grandma's chocolate chip cookie recipe, or add the punchline to a joke if you hit the send button too quickly. The choice is yours. Messages will always show when they have been edited, and you can click on the "Edited" indicator to see the full edit history for any edited messages. Update the past in the present to prevent future confusion today!

6.33:

Now you can edit a message with a right click after it has been sent! Fix a tpyo, include the missing ingredient in grandma's chocolate chip cookie recipe, or add the punchline to a joke if you hit the send button too quickly. The choice is yours. Messages will always show when they have been edited, and you can click on the "Edited" indicator to see the full edit history for any edited messages. Update the past in the present to prevent future confusion today!

To add to the confusion: I'm currently using Signal 6.32 and it already has edit functionality by pressing arrow-up key.

Fixing this?

I guess the straight-up fix is to edit current release notes to say exactly when the Edit function was introduced.

If subsequent releases have bug fixes for the same feature, the release entry not summarize something that can be understood differently from previous entries like "we recently introduced an edit function and this release contains a number of bug fixes, including [...]"

Secondarily, I think the underlying issue is a lack of alignment between development and the UX-approach to in-app release notes announcements. This is already discussed in https://github.com/signalapp/Signal-Desktop/issues/5325 so I would just offer this overview of adjustments that could help avoid similar confusion...

• If the changelog was aligned with PR numbers or issue numbers, it would be easier to be systematic about its entries. A list of PR numbers next to each changelog entry would work.
• I'd also suggest removing pre-releases or removing their descriptions once stable releases are out. The overview is hard on the eye.
• There's also a conventions suggesting topics like "Added", "Fixed", "Changed" etc: https://keepachangelog.com/en/1.0.0/

[ayumi-signal]

@benjaoming Thanks for taking time to review the changelog and share your thoughts and suggestions about them.

The recent update where we said Edit message was introduced in two versions was confusing, sorry about that. This feature required us to turn it on the server, but we could only let people know about it in client specific changelogs. It didn't match a specific client version, so we had to do our best with the release notes. In the future we'll do better to clearly communicate what's happening.

Regarding release notes in general, appreciate your thoughts on it. I've shared your feedback about changelog best practices with the team. In general for feedback like this the Community forum is a good place to voice that feedback. Consider the Desktop Feature Requests or Desktop General Discussion. This helps us to make design decisions for future work. Thank you again!