Re: flathub now supports tag, but which id to use for KDE? (was: Re: Defining a developer name for our applications metadata)

2024-02-26 Thread Friedrich W. H. Kossebau
Am Donnerstag, 22. Februar 2024, 15:58:53 CET schrieb Friedrich W. H. Kossebau: > Am Dienstag, 30. Januar 2024, 18:34:46 CET schrieb Timothée Ravier: > > Hi folks, > > > > Flathub is now requiring that applications define a "developer_name" tag > > in > > their metadata (see [1], [2]). > > > > W

flathub now supports tag, but which id to use for KDE? (was: Re: Defining a developer name for our applications metadata)

2024-02-22 Thread Friedrich W. H. Kossebau
Am Dienstag, 30. Januar 2024, 18:34:46 CET schrieb Timothée Ravier: > Hi folks, > > Flathub is now requiring that applications define a "developer_name" tag in > their metadata (see [1], [2]). > > What do folks think would be a good value for our application there? > > Based on the suggestion in

Re: Defining a developer name for our applications metadata

2024-02-02 Thread Johannes Zarl-Zierl
Hi Albert, Am Dienstag, 30. Jänner 2024, 22:27:22 CET schrieb Albert Astals Cid: > "The KDE Community" is like "ATM Machine", KDE is *already* the community. I have to say this is definitely *not* like "ATM Machine". At least I hope nobody is saying "the C in KDE stands for Community"... ;-) Ap

Re: Defining a developer name for our applications metadata

2024-02-02 Thread Timothée Ravier
On Fri, Feb 2, 2024 at 5:08 PM Johnny Jazeix wrote: > Hi, > > Just to be sure, do we know which appstream version do we use to validate > our appdata files ( > https://invent.kde.org/frameworks/extra-cmake-modules/-/blob/master/kde-modules/appstreamtest.cmake) > and if the deprecated tag will iss

Re: Defining a developer name for our applications metadata

2024-02-02 Thread Johnny Jazeix
Hi, Just to be sure, do we know which appstream version do we use to validate our appdata files ( https://invent.kde.org/frameworks/extra-cmake-modules/-/blob/master/kde-modules/appstreamtest.cmake) and if the deprecated tag will issue a warning, an error or nothing in it? Cheers, Johnny Le ve

Re: Defining a developer name for our applications metadata

2024-02-02 Thread Nate Graham
Sounds good! Thanks for tackling this, Timothée. Nate On 2/2/24 08:55, Timothée Ravier wrote: Hi everyone, Following suggestions in the thread, I'll start updating our AppStream metadata with: ``` KDE ``` Thanks -- Timothée Ravier CoreOS co-Team Lead Red Hat

Re: Defining a developer name for our applications metadata

2024-02-02 Thread Timothée Ravier
Hi everyone, Following suggestions in the thread, I'll start updating our AppStream metadata with: ``` KDE ``` Thanks -- Timothée Ravier CoreOS co-Team Lead Red Hat trav...@redhat.com

Re: Defining a developer name for our applications metadata

2024-02-01 Thread Timothée Ravier
On Wed, Jan 31, 2024 at 8:57 AM Ben Cooksley wrote: > Wait, so Flathub has begun requiring an older tag that the Appstream > developers have deprecated? > > So we need to add tags to our metadata that are already deprecated and > which are going to result in future failures of our own unit tests

Re: Defining a developer name for our applications metadata

2024-01-31 Thread Matthias Klumpp
Am Mi., 31. Jan. 2024 um 08:50 Uhr schrieb Ben Cooksley : > On Wed, Jan 31, 2024 at 7:04 AM Timothée Ravier > wrote: > >> Hi folks, >> >> Flathub is now requiring that applications define a "developer_name" tag >> in their metadata (see [1], [2]). >> >> What do folks think would be a good value f

Re: Defining a developer name for our applications metadata

2024-01-30 Thread Ben Cooksley
On Wed, Jan 31, 2024 at 7:04 AM Timothée Ravier wrote: > Hi folks, > > Flathub is now requiring that applications define a "developer_name" tag > in their metadata (see [1], [2]). > > What do folks think would be a good value for our application there? > > Based on the suggestion in the documenta

Re: Defining a developer name for our applications metadata

2024-01-30 Thread Matthias Klumpp
Am Di., 30. Jan. 2024 um 22:27 Uhr schrieb Albert Astals Cid : > > El dimarts, 30 de gener de 2024, a les 22:06:01 (CET), Nate Graham va > escriure: > > What sprang immediately to my mind was simply "KDE". Short and sweet. > > Agreed > > "The KDE Community" is like "ATM Machine", KDE is *already* t

Re: Defining a developer name for our applications metadata

2024-01-30 Thread Albert Astals Cid
El dimarts, 30 de gener de 2024, a les 22:06:01 (CET), Nate Graham va escriure: > What sprang immediately to my mind was simply "KDE". Short and sweet. Agreed "The KDE Community" is like "ATM Machine", KDE is *already* the community. Also "KDE" works in all languages while "The KDE Community" i

Re: Defining a developer name for our applications metadata

2024-01-30 Thread Nate Graham
What sprang immediately to my mind was simply "KDE". Short and sweet. Nate On 1/30/24 10:34, Timothée Ravier wrote: Hi folks, Flathub is now requiring that applications define a "developer_name" tag in their metadata (see [1], [2]). What do folks think would be a good value for our applic

Re: Defining a developer name for our applications metadata

2024-01-30 Thread Johnny Jazeix
Hi, I recently added an application in flathub and found https://discourse.flathub.org/t/deprecated-developer-name-element/5746 which is related to the subject. I used appstreamcli to generate the appdata and it changes to . The new format emits a warning on flathub linter (missing developer_name

Re: Defining a developer name for our applications metadata

2024-01-30 Thread Ingo Klöcker
On Dienstag, 30. Januar 2024 18:34:46 CET Timothée Ravier wrote: > Flathub is now requiring that applications define a "developer_name" tag in > their metadata (see [1], [2]). > > What do folks think would be a good value for our application there? > > Based on the suggestion in the documentation

Defining a developer name for our applications metadata

2024-01-30 Thread Timothée Ravier
Hi folks, Flathub is now requiring that applications define a "developer_name" tag in their metadata (see [1], [2]). What do folks think would be a good value for our application there? Based on the suggestion in the documentation [3], I started making PRs [4] [5] [6] [7] for our KDE Apps with "