Problem with duplicate <release> versions in AppData files

[Heiko Becker]

Hello Ingo,

On Monday, 21 June 2021 22:55:03 CEST, Ingo Klöcker wrote:
> I thought, I'd ask you, because you have updated the AppData files of 
> Kleopatra a few times. Building the flatpak of Kleopatra failed with the 
> error:

Not entirely by myself, this is scripted as the part of the release process 
of KDE Gear [1][2].

> ```
> Running appstream-compose
> Processing application org.kde.kleopatra
> org.kde.kleopatra.desktop:         AppData problem: tag-invalid : <release> 
> version was duplicated
> Error loading AppData file: AppData file /app/share/appdata/
> org.kde.kleopatra.appdata.xml was not valid
> ```
> [...]
> appstream-compose does not seem to like multiple <release> tags 
> with identical 
> version properties. I checked the AppStream specs at
> https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-releases
> but there is no requirement that different <release> tags have different 
> version properties. In fact, the version property seems to be optional.
>
> Do you know whether the AppStream file of Kleopatra is invalid or whether 
> appstream-compose is wrong in requiring different version properties for 
> different <release> tags?

I read the spec the same way you do and appstreamcli validate --pedantic 
validates the file successfully. But leaving that aside I don't think that 
the expectation that a release (identified by a version) only has one date 
is unreasonable. I can't say much about flatpak as such, but I'm forwarding 
this to the release-team ML, which may have more knowledgeable people.

Besides that, I can think of a few ways to fix this.

1) Indicate for the scripts to skip kleopatra
2) Change the scripts to not add duplicate versions
3) Change the version manually before every release of KDE gear
4) Adopt the RELEASE_SERVICE_VERSION scheme

1) is probably bad because distros want appstream metadata with versions, 
and I think flatpak especially insists upon that as well, although it 
obviously still could be added manually. 2) would show somewhat confusing 
information.
3) would work, but obviously needs someone to remember to do that. 4) would 
basically do that by yet another script running during the release process. 
It would also make automatically adding bugzilla versions work and, more 
importantly, would allow users to differentiate between releases. It's also 
what our guideline on the topic suggests [3].

Regards,
Heiko

[1] 
https://invent.kde.org/sysadmin/release-tools/-/blob/master/add_appstream_versions.sh
[2] https://invent.kde.org/sysadmin/appstream-metainfo-release-update
[3] https://community.kde.org/Guidelines_and_HOWTOs/Application_Versioning