validation demands releases being in-order but spec does not have that requirement

[muelli]

I am trying to automatically add a release to an appdata file. I could read the XML, add a release node, and serialise the XML back out to a file. I prefer doing it in-place, though, to keep the visual noise in the diff low.

So far, my best bet has been xmlstarlet:

xmlstarlet ed --ps --inplace -L -s /component/releases -t elem -n releaseTMP -v "description" \
    -i //releaseTMP -t attr -n "version" -v "20190801" \
    -i //releaseTMP -t attr -n "date" -v "2019-08-01" \
    -r //releaseTMP -v release \
    *appdata.xml

but it appends to the releases rather than prepending.

Then, validation fails:

• tag-invalid           : <release> versions are not in order [20161005 before 20190801]

I could not find the requirement it complains about in the spec. So I guess it's either a bug in the spec or in the validator.

In any case, a tool for adding a new release to the appdata would be good. I have tried appstream-util incorporate my.appdata.xml helper.xml new.xml but it bails out with a rather meaning less error: No valid root node specified, so I'm stuck there. I couldn't find an example of how the "new.xml" needs to look like.

FWIW: My appdata file is: https://github.com/flathub/org.fontforge.FontForge/blob/38c321ed7a91382c871c9de171778002ff746e3e/org.fontforge.FontForge.appdata.xml#

[hughsie]

They do need to be in order, lots of tools assume "first == newest" for better or worse. Out of interest, what's you're "input" for the release notes?

[muelli]

They do need to be in order, lots of tools assume "first == newest" for better or worse.

Fair enough. I'm not questioning it right now. But the spec doesn't say. Do you think it should go into spec?

Also, do you know off the top of your head which tools do not sort the releases themselves and whether bug reports have been filed?

Out of interest, what's you're "input" for the release notes?

I have used the Github API through lastversion. It returns a description field for the release. I guess it'll either use the formal Github release description or fall back to the git tag's message.

I plan to automate updates for flathub packages a bit more. Debian's watch mechanism is a bit too involved for me. And release-monitoring.org provides a version number, only. While that's already good, I was wondering whether it could be taken further.

[ximion]

They do need to be in order, lots of tools assume "first == newest" for better or worse. Out of interest, what's you're "input" for the release notes?

They really shouldn't do that, but well - having the latest version at the top also greatly improves readability. My appstream-generator tool will reorder the releases to be in the correct order anyway when generating distro metadata. So, I simply adjusted the spec to reflect the status quo in https://github.com/ximion/appstream/commit/60bb676800256c686dce2b4bf8c03b15f9bc576d - the appstreamcli validator was actually already warning about ordering, but only as pedantic check. I'll make this a warning now and see what breaks (warnings and errors cause validation to fail).

EDIT: libappstream was sanitizing loaded data by automagically sorting releases when loading XML/YAML. This has been removed now and its validator will spit out a warning properly now when releases are not sorted correctly (the automatic sorting will still happen when serializiong data as XML or YAML though). This effectively means that the reference implementation as well as libappstream-glib both assume that releases are ordered correctly now. So, the spec issue is definitely dealt with, and this issue can potentially be closed.