For some history and background, see a prior attempt to do release notes in D12163.
We got pretty far, but some process concerns derailed it. I think we could probably get it done if we adjust our process or the scripts used to facilitate it accordingly. I noticed recently that GNOME apps released for 3.32 now have release notes in AppStream. It looks really good in Discover:
They even list the contributors who implemented each new feature or bugfix, which is really nice!
@volt4ire your notification reminded me about this!
We discussed the subject at the recent Usability & Productivity sprint. Our conclusion was that the biggest barrier was making sure the release notes are all translated. The best solution we could think of was to get a feature added to AppStream itself to support hosting release notes (including translations) on a website, and make the appdata.xml file pull its content from there. The request is tracked here: https://github.com/ximion/appstream/issues/240. Happily the AppStream maintainer @mak seems supportive, so I suppose it's only a matter of time. :)
(Adding people to the subscribers list by hand makes me think maybe we need a "Release team" group on Phab where this kind of work can be coordinated)
@ngraham Thanks I'm really glad to hear there's progress on this - it sounds like a great solution!
New versions of appstreamcli can add release information from NEWS files as well as YAML files containing the change information. That should make it easier for people to adopt this feature, if integrated into the build process (I could create an example for that with cmake, I guess).
Remoting release information to web locations will definitely take a while, because not only does this need to be specified, but it also needs to percolate through the whole stack so this works even on older distributions. So, it's better not to wait completely for that solution, but rather start with the existing one and then switch to the other once it becomes available.
(If people would write release notes while working on the release, translators would have a chance to actually translate them before a release is made. Unfortunately even then KDEs translation system makes every metainfo translation *really* hard compared to how GNOME does it, where stuff like this is much simpler)
If the release notes are complete when the freeze happens, which is the rule that should be followed, I don't see how the translation system could get in the way. What is the technical difference with the Gnome system (apart from their recent switch to pure gettext for appdata files), and how would impact the translations?
In GNOME the untranslated metainfo files are kept separate from the translations which are in .po files. During build, the build system just assembles the final localized XML file from that. In KDE, translations are checked in directly into the XML file. This makes adding and changing release notes really annoying, because a human needs to read through the file containing translations, which is visual cruft and will be a lot more if release notes are contained in there as well. Compare https://cgit.kde.org/dolphin.git/tree/src/org.kde.dolphin.appdata.xml and https://gitlab.gnome.org/GNOME/nautilus/blob/master/data/org.gnome.Nautilus.appdata.xml.in.in for an example. The latter is much nicer for humans to edit, and release information is automatically merged in at build time.
The other problem is that when using appstreamcli news-to-metainfo to generate the release info from a different, easier to write filetype, doing that in KDE will be hard with the current system, as it basically has to be done on the machine merging in the translations and rewriting the final XML file. Usually the workflow is 1) Merge in release XML into the existing untranslated file and write a temporary one and 2) translate that result with itstool. With KDEs current system, people would have to write the metainfo XML file and also store a NEWS file in a known location, and then the translation machine would need to do the merging and splitting, which is less flexible and will result in less readable files (as appstreamcli removes all comments and extra whitespaces from the metainfo file when rewriting it, and those are the things humans need for a pleasant experience).
So tl;dr it's not impossible to have basic support for this in KDE right now, but it may be a bit less fun than it is for GNOME.
Writing release notes as-you-go isn't a bad idea in general but doesn't help us here because the promo team likes to rewrite and polish up the final announcement. This can only be done at the very end once all the raw data for the notes has been collected, which can't happen until all the features and bugfixes they want to mention have already been committed.
I would say that those are different cases. The release notes for each application are specific for each application. The announcement would then use the various release notes as input and build a more descriptive description of what happened.
I mean ideally the promo team would do that for each individual app. But that might be asking a bit much of them.
With the new "Release Service" idea, we're basically giving back part of the promo to apps and letting the promo people actually focus on "the important apps", whatever those are :D
Yes, the plan still needs fleshing otu