I've seen the same thing done within the ticketing system. It's useful when you might want non-developers to contribute to the notes.
Being able to dedicate a tag, field, or work item type is pretty handy.
Being able to dedicate a tag, field, or work item type is pretty handy.
Ultimately we also decided to go with the tickets, but I am curious what your reasoning was to go that way?
The primary advantage of the ticket-based approach is that it's much easier to involve non-dev stakeholders. I'd choose it whenever other people might want input in the process. Most ticketing systems also offer a lot of flexibility, you could incorporate the ticket name, group tickets by relation, block completion states, act on deployments, etc. The ability to edit the note without rebasing is a major bonus as well.
The git-based approach potentially leads to a more readable commit history, and strongly associates any release notes with the actual code change. On the other hand, it's a pain to edit and can distract devs while they're problem solving if not setup well.