In bug 843497 the ability was added to notify users that their system is no longer supported via app update. The minimal update.xml required is as follows: <?xml version="1.0"?> <updates> <update type="major" unsupported="true" detailsURL="http://moreinfo"></update> </updates> Where type can be either major or minor. I could possibly remove this requirement but it would add complexity to the client code. Where http://moreinfo is a link for more information as to why the system is unsupported (possibly the requirements page). akeybl / lsblakk, the update.xml will need to include a link to the requirements page for the release and it might be simpler to have a "latest release" requirements page so the update.xml doesn't have to change the link for each release.

Is there a timeline attached to this at all ?

I don't think we have any plans to remove support for an OS at this time so I don't think so but akeybl / lsblakk should be able to answer whether there is a timeline attached to this.

needinfo for comment #1

(In reply to Robert Strong [:rstrong] (do not email) from comment #3) > needinfo for comment #1 Sooner the better, will bring up in the channel meeting. We want this functionality in place a few releases before our next desupport (unknown).

Nick, just making sure that you saw comment #4.

Moving this to the new component for the update server rewrite, where it can join the list of other functionality we need to implement. As long as we get a week or two's notice of the intention to desupport it should be straight forward to implement & deploy this.

mass priority change after component move

We'd like to drop support for an OS in bug 1003270, so this might be desired in the near term.

Thanks for the heads up.

(In reply to :Gavin Sharp (email gavin@gavinsharp.com) from comment #8) > We'd like to drop support for an OS in bug 1003270, so this might be desired > in the near term. We'd also need to have this shipped for Release users before we EOL to make this happen. We're actively working towards it, but there's no firm timeline yet.

This seems like it would be pretty easy to do once bug 1021018 is fixed. We could create an UnsupportedBlob which would store the detailsURL, and its XML generation methods would generate the XML described in comment #0. We already have specific rules for unsupported OS', they just currently point at empty blobs and serve an empty update XML.

This should be enough functionality to desupport a subset of a single OS. In the event of wanting to deprecate two different OS at the same time, and wanting to use separate web pages, we can have two releases and rules. I'll set r? on bhearsum once he's allowing that again.

Updated the pull request to remove the showSurvey attribute, since bug 843497 did that at the same time as it added unsupported. I've been working on this because of bug 1186229 / bug 1227023.

Commits pushed to master at https://github.com/mozilla/balrog https://github.com/mozilla/balrog/commit/92bc15281ba5629d35f45246952f1cfc08780cf2 Bug 886543, supported sending xml about OS desupport https://github.com/mozilla/balrog/commit/c2ceae0cc3383dbdcb823edc89c20f7717d8e219 Merge pull request #30 from nthomas-mozilla/desupported Bug 886543, supported sending xml about OS desupport

Over to Ben to handle deploy at some point before 45.0 gets to beta, where we will enable GTK3.

Comment on attachment 8696492 [details] PR to support desupporting This is landed and deployed to production.

This is in production, and enabled for older versions of GTK on Beta now. Eg: update requests like https://aus5.mozilla.org/update/3/Firefox/44.0/20160123151951/Linux_x86-gcc3/en-US/beta/Linux%203.0.0-15-generic-pae%20%28GTK%203.1.1%29/canonical/1.0/update.xml?hueton will receive: <updates> <update type="minor" unsupported="true" detailsURL="https://www.mozilla.org/firefox/45.0beta/system-requirements/"> </update></updates>