As far as I can tell, there is really no good mechanism to make aware of changes to existing modules and extensions in terms of functionalities (e.g., new features, behavior change etc) to the end user.
I am wondering if there can be a feature in Slicer splash window for people to click and see what’s new and changes in a separate window. I am not sure how infrastructure wise it will work, but perhaps extension developers and core maintainers can self-report in few sentences.
That’s a good point the release notes are very comprehensive, but we don’t have a direct link to them in the Welcome module.
@pieper, yes those are very useful, but I am not talking about just feature releases. For example that list lacks the new markup features such as curves, which were after the 4.10.1, I think.
So, someone switching from 4.10.1 to a nightly wouldn’t know that those were added immediately unless they pay close attention to the forum.
True - maybe we should start a discourse topic on “new in the nightly” and encourage people to post there when they update core code to extensions. We could link that from the Welcome module (or splast screen) too. It would simplify the task of collecting release notes when the actual release happens.
Yes, I think that will work.
To compile the release notes, I was initially thinking of the following:
name-of-the-topic.rst file for each topic branch making a noteworthy change.
Next Release section would be automatically generated with links to each documentstart a discourse topic on “new in the nightly”
This is also an interesting idea. Before each release, should we automatically scrap and combing the markdown of each discourse post ? I can foresee some challenge in managing this.
What do you mean exactly by encourage people to post there when they update core code to extensions ?
We could link that from the Welcome module
Adding a link to the summary of features and fixes added since the last release makes sense.
Oops, that was a typo - I meant “update core code or extensions” 
I like the idea of including the blurb about new functionality directly in the pull request and then adding automatically to the documentation. This sounds easier to manage, since it can be part of the code review before merging.