Fix deprecated top-level developer_name in AppData XML

[musicinmybrain]

Use the name element in a developer block instead, as recommended by appstreamcli 1.0.0.

This fixes all warnings when validating the AppData XML file, although there are still informational messages:

I: com.github.alecaddd.sequeler:10: description-first-para-too-short
     Easily connect to your local or remote database
   The first `description/p` paragraph of this component might be too short (< 80 characters).
   Please consider starting with a longer paragraph to improve how the description looks like in
   software centers and to provide more detailed information on this component immediately in the
   first paragraph.

I: com.github.alecaddd.sequeler:513: developer-id-missing
   The `developer` element is missing an `id` property, containing a unique string ID for the
   developer. Consider adding a unique ID.

I: com.github.alecaddd.sequeler:558: nonstandard-gnome-extension kudos
   This tag is a GNOME-specific extension to AppStream and not part of the official specification.
   Do not expect it to work in all implementations and in all software centers.

✔ Validation was successful: infos: 3, pedantic: 3

[musicinmybrain]

Let me clarify that appstream 1.0.0 has not yet been released, and my appstream is a pre-release as currently packaged in Fedora Linux Rawhide (the development version of the OS), corresponding to ximion/appstream@d88ed03. See also ximion/appstream#244.

[Alecaddd]

Thanks for the contribution.
Do you have any way of knowing when these changes to the appdata format will be released and adopted?
Also, how does this play along for systems with the old appdata format?

[musicinmybrain]

Thanks for the contribution. Do you have any way of knowing when these changes to the appdata format will be released and adopted?

The release of appstream 1.0.0 was a couple of weeks ago. It will continue to filter into fast-moving distributions over the next few months; it’s already in Fedora Rawhide and will be in Fedora 40, which releases in spring 2024.

Also, how does this play along for systems with the old appdata format?

I found that the result of this PR still validates with appstream-util validate-relax --nonet and with appstreamcli validate --no-net (for pre-1.0 versions of appstreamcli). That’s about all I can say.

I assume that the developer information might not be properly displayed in app stores / software centers that don’t use appstream 1.0.0 or later, but I don’t have a straightforward way to test what actually happens.

[musicinmybrain]

As of appstream 1.0.2, the deprecated developer_name tag has been downgraded to info (I think this happened in 1.0.1), but in this PR, appstreamcli validate has started warning (and exiting with nonzero status) about the lack of an id property on the developer element:

I: com.github.alecaddd.sequeler:10: description-first-para-too-short
     Easily connect to your local or remote database
   The first `description/p` paragraph of this component might be too short (< 80 characters).
   Please consider starting with a longer paragraph to improve how the description looks like in
   software centers and to provide more detailed information on this component immediately in the
   first paragraph.

W: com.github.alecaddd.sequeler:513: developer-id-missing
   The `developer` element is missing an `id` property, containing a unique string ID for the
   developer. Consider adding a unique ID.

I: com.github.alecaddd.sequeler:558: nonstandard-gnome-extension kudos
   This tag is a GNOME-specific extension to AppStream and not part of the official specification.
   Do not expect it to work in all implementations and in all software centers.

✘ Validation failed: warnings: 1, infos: 2, pedantic: 3

Per https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-developer, “The element should have a id property, containing a unique ID to identify the component developer / development team. It is recommended to use a reverse-DNS name, like org.gnome or io.github.ximion, or a Fediverse handle (like @[email protected]) as ID to achieve a higher chance of uniqueness.”

I’m modifying this PR to propose using com.alecaddd as the developer ID.