[bmalehorn]

I have written exactly that kind of changelog. Let me explain why.

I write the changelog for a product. In fact I write two changelogs - one for engineers and one for customers.

Engineers:

- [New Feature] Added ability to ___

- Improved logging on ___

- Fixed a memory leak on ___

Users:

- [New Feature] Added ability to ___

Not every change can be explained in one sentence to users. Internal logging? Memory leaks? You're speaking a foreign language. Those entries must be thrown out when making the changelog for users.

Eventually, there comes a release when you have thrown everything out. What do you write? "Bug fixes & enhancements".

[_asummers]

You could say something like "fixed stability in account management" or "fixed crash issues across application, improving stability across board". I sympathize with not wanting to go into more detail than would be generally understood by the audience, but there's a large chasm between "bug fixes" and that. If I was experiencing those bugs, I can now expect them to be fixed and I'm now in a better spot if I see them again to say "hey you didn't QUITE fix that in release X". If I see "bug fixes", I can't guess what happened in that release.

[engerland]

We already have our bug tracker for the engineers so why do twice the work? Most engineers don't care once the product is 'out' they only care what they're working on.

So we create our change log (they are part of our 'release notes' actually) with only the user in mind but we reference the bug tracker number next to it.

This is what we check in to the 'source' for the release notes.

Then when we post to the 'outside world' we just remove those tracker numbers (takes a few seconds).

That way the engineer can see the 'easy to understand conceptually' bug fix/enhancement and if they want to know more then they can see the Tracker reference and go and look up the 'real meat - with all the discussion and threads etc.

For those bug fixes that we 'don't' document we have our source code software.

[jaxn]

We have 4 sections to every changlog release: New, Improved, Fixed, and Internal

We maintain a CURRENT_CHANGES.md with those sections. When we do a release, we move the contents of CURRENT_CHANGES to a new entry in RELEASE_NOTES.md.

One of these days, I will get around to writing something that displays RELEASE_NOTES in the app, without the Internal section