Warn about apps built against EOL runtimes

[meisenzahl]

Re: #1803

Peek.2022-01-07.12-05.mp4

[cassidyjames]

An initial pass; feel free to push back on any changes! But here's what I'm thinking:

• Flatpak seems to use eol as the end of life terminology consistently rather than deprecated, so I think it makes sense to align our code to that for clarity.
• However, End of Life might not really mean what users expect, especially when we're talking about the runtimes and not necessarily the app itself (unless I'm reading this wrong, in which case, oops!).
• So, I made the user-facing copy more generic; this also reflects somewhat how iOS and Android talk about apps made for an older version of the OS, but we can't really say "for an older version of elementary OS" because that's not exactly how runtimes work.
• Lastly, I don't see us needing to care about the number of EOL runtimes, so I refactored that into a bool. Edit: I see you started with an is_eol bool so this was basically just reverting back to that while using a more precise name; feel free to change this further if it can be simplified.

[cassidyjames]

I also want to note that this doesn't precisely close #1803; that issue is about a mismatch between the OS version and the runtime version for curated apps, while this PR focuses on EOL runtimes. I think both are valuable, but what @danrabbit is asking for is a little different; if I install an app build against the not-EOL OS 6 runtime on OS 7, it might be useful to still point out that the app was built for OS 6 and thus might be missing out on features/integration.

In that situation, I think EOL warning would take precedence, but we'd need to do some version matching and only look at curated apps, etc. I think that is a separate PR, though.

[danirabbit]

Yeah for EOL I'd be inclined to use a much larger warning like a floating infobar

[cassidyjames]

@danrabbit I think I'm still fine with using our content warning space for EOL runtimes, as it keeps the security/updates/expectations information in one place, but I could see that argument, too. 🤔

[cassidyjames]

Alright, this reverts back further to basically where your is_eol bool was, but using more precise terminology. Does that make sense?

[meisenzahl]

I also want to note that this doesn't precisely close #1803; that issue is about a mismatch between the OS version and the runtime version for curated apps, while this PR focuses on EOL runtimes. I think both are valuable, but what @danrabbit is asking for is a little different; if I install an app build against the not-EOL OS 6 runtime on OS 7, it might be useful to still point out that the app was built for OS 6 and thus might be missing out on features/integration.

I must have missed something in the issue 😅

But that shouldn't be a problem to implement. I am preparing a branch based on this PR.

[cassidyjames]

I'm happy with this as an initial pass UX wise. It adds value and uses existing mechanisms to present an important bit of information. I think I'd still like a pass from @elementary/desktop-developers in case I missed anything code-wise, though!

[cassidyjames]

oops ignore this accidental double review

Addressed