This is something we've discussed before. The trouble is, we can do it two ways and both have problems:
1) Doing it manually requires somebody to manage it, and while it's not a lot of work it is tedious and not the best use of our resources. It's also error prone and likely to get stale, which means it's integrity as a source of information is compromised.
2) Doing it programmatically with our existing commit-history to the codebase would be the ideal way, but right now that wouldn't work so well because the way in which we deploy our changes adds so much noise that it would be unreadable/useless to the average user.
The correct solution is to change our current deployment process in a way that supports grouping feature changes so that they could be easily filtered and publicized. This is something that I'm working on, but is not as easy as it sounds because it requires a non-trivial amount of additional work for all developers involved, including Stefan. I'm working on some things to make this process as easy as possible but it will take some time and cleverness to get it right, and to convince everybody to work within its design.
Got a few bucks? The Imperial Tip Jar is accepting contributions!