[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-release-team
Subject:    Re: Problem with duplicate <release> versions in AppData files
From:       Albert Astals Cid <aacid () kde ! org>
Date:       2021-06-22 17:17:47
Message-ID: 6766565.J7TkErNQl9 () xps
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]