Problem with duplicate <release> versions in AppData files

[Albert Astals Cid]

El dimarts, 22 de juny de 2021, a les 0:01:05 (CEST), Heiko Becker va escriure:
> 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].

Yeah, you either want 3 or 4, if we're making a release, that release should have a different version number, otherwise what do you do when someone reports a bug against 3.1.15 which of the N releases that had 3.1.15 as version number is it?

Doing 3 gets boring, i did for Okular for years and it's not really something i would recommmend.

If you're not convinced about dates as versions (versions have each time less meaning for users, see how firefox gets one release almost every other week and chromium version is 91.0.4472.114) I would at least recommend to adopt what khelpcenter is doing and append the date to your version number so you have something like 3.1.15.20040, 3.1.15.20041, etc.

Cheers,
  Albert

> 
> 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
> 
>