You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like the AppStream spec to support (or maybe just allow) any metadata that is needed for the different app stores including the proprietary ones. Some of those app stores, e.g. Microsoft Store, require very specific information which makes little sense for other stores, e.g. the store ID of the application and logos with special dimensions. Moreover, we may want to use different metadata for the Microsoft Store or F-Droid or Google Play than in general (Linux) app stores, e.g. Windows-specific or Android-specific screenshots.
To solve this I propose to support/allow something like this (in <component>):
Each <store> can contain store-specific metadata and overwrite metadata specified in <component>. In the example, <applicationId> and <images> are store-specific entries while the <screenshots> in <store> overwrite the <screenshots> in <component>. This is a more general solution than #390 because it allows any component-metadata to be overwritten for specific platforms (provided there's a relation between platforms and stores).
Additionally, I'd a discrete list of features as proposed in #388. Alternatively, we could add this to the <store> entry, so that the features can be added natively to the Microsoft Store for our apps.
The rationale for adding this to AppStream is that we could then generate the metadata needed for a specific store from the app's AppStream metadata (as we already do, but some metadata is missing in AppStream). Consumers of AppStream (except those explicitly using the store-data) should ignore anything in <stores>. Linters may support <stores>. In particular, they could lint tags that overwrite common component tags. But they should ignore any tags unknown to them.
The text was updated successfully, but these errors were encountered:
Sorry, but metadata for different app stores is out of scope for AppStream. We don't control them and can't play catch-up with their features, You can use the custom tag though to add some information that you may need, and if there is something that is generally useful, we could add that to AppStream proper, as a generic feature.
I would like the AppStream spec to support (or maybe just allow) any metadata that is needed for the different app stores including the proprietary ones. Some of those app stores, e.g. Microsoft Store, require very specific information which makes little sense for other stores, e.g. the store ID of the application and logos with special dimensions. Moreover, we may want to use different metadata for the Microsoft Store or F-Droid or Google Play than in general (Linux) app stores, e.g. Windows-specific or Android-specific screenshots.
To solve this I propose to support/allow something like this (in
<component>
):Each
<store>
can contain store-specific metadata and overwrite metadata specified in<component>
. In the example,<applicationId>
and<images>
are store-specific entries while the<screenshots>
in<store>
overwrite the<screenshots>
in<component>
. This is a more general solution than #390 because it allows any component-metadata to be overwritten for specific platforms (provided there's a relation between platforms and stores).Additionally, I'd a discrete list of features as proposed in #388. Alternatively, we could add this to the
<store>
entry, so that the features can be added natively to the Microsoft Store for our apps.The rationale for adding this to AppStream is that we could then generate the metadata needed for a specific store from the app's AppStream metadata (as we already do, but some metadata is missing in AppStream). Consumers of AppStream (except those explicitly using the store-data) should ignore anything in
<stores>
. Linters may support<stores>
. In particular, they could lint tags that overwrite common component tags. But they should ignore any tags unknown to them.The text was updated successfully, but these errors were encountered: