Support flagging a release as end of life

[cassidyjames]

Flatpak has a concept of a package being end of life, but it seems like this would be useful to be communicated in the AppStream data, i.e. on a release?

Brought up here: elementary/appcenter#1020

A commit in flatpak can be marked end-of-life, as in it is no longer expected to get updates, and with that it can have a custom message or redirect to a new package replacing it. Appcenter should expose this information in the UI in some form.

The basic API docs are here:

• http://flatpak.github.io/flatpak/reference/html/FlatpakTransaction.html#FlatpakTransaction-end-of-lifed

• http://flatpak.github.io/flatpak/reference/html/FlatpakRemoteRef.html#FlatpakRemoteRef--end-of-life

[ximion]

This is already supported, check out the date_eol property of release entries: https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-releases

[cassidyjames]

@ximion ah, thanks! I was having a hard time finding that by searching the docs, but that seems to make sense.

[cassidyjames]

@ximion ah, what appears not to be supported in AppStream still is this bit:

and with that it can have a custom message or redirect to a new package replacing it

That seems important to an implementation in an app store to share the message to users and suggest a replacement package.

[ximion]

ah, thanks! I was having a hard time finding that by searching the docs, but that seems to make sense.

I am currently working on improving the doc layout by switching away from Publican (the primary reason for that was that Publican adds zero-width-space unicode characters into code blocks, which creates invalid metainfo files when people copy&paste from there - which is an easy mistake to make, I fell into that trap multiple times already).

@cassidyjames AppStream doesn't know about "replacement packages" and it's not AppStream's call to make to just swap out an application on the user's computer. You could kind of imitate something like this by adding a <requires/> block to the AppStream component that is end-of-life and make it depend on the new component and then make the current release of the old one end-of-life... I don't think that's a good call to make though. I think the old app should just remain installed, maybe show an info message about expiry to the user once, and then installing an alternative should be an explicit action from the user.

[cassidyjames]

@ximion I don't think anyone is suggesting to swap out packages without user consent—we would simply be informing a user of the EOL state along with a reason (if provided), plus giving a recommendation to install a replacement package (if one exists). We have come across instances with both Debian packages and Flatpaks where a package is considered end-of-life with a recommendation for a replacement. We can manually use the Flatpak API and/or try and scrap something together with existing AppStream API, but perhaps it would be useful to provide the same sort of information as Flatpak in the AppData itself.

[ximion]

Hmm... Couldn't the app author simply do that in the release description (make suggestions on what to use next, that is)? Make one final release, set an EoL date, and the software center then shows the user the end-of-life relase notes a lot more prominently once the app ran over the end of its life and no more up-to-date release was found in the software sources.

[cassidyjames]

@ximion I suppose that is possible, though it seems a little less reliable than a dedicated field. I guess I was imagining the software source (i.e. the AppCenter remote in this case) would be adding the EoL information into the AppStream data if needed, which seemed easier if it was a dedicated field. But we could modify the description as well. Hm.