eol dates

[joshtrichards]

I think it would be helpful if we provided the projected end-of-life date for the currently in-service major within the overview provided in the Web UI. This would make it clearer to admins where their installations stand.

Right now the eol field is a simple true/false.

Since our release cadence and end-of-life policies are fairly consistent and transparent I suggest we either change this to an actual date field or add an eol_projected (or similar) field.

This would permit us to easily capture the projected end-of-life date and then display an actual date in the Admin Web UI.

It also might be useful to consider adding a similar field that has the projected next maintenance release date in it since we also already publish this information.

[joshtrichards]

Currently thinking I'll add an eol_branch_projected field to the existing updater_server release response. It'll contain YYYY-MM.

PR #1053 might help here too, since the planned eol date is in the major_versions.json we can populate it all the way through to that (unless that json could be accessible on its own somewhere?).

I also want to add a published or similar field to each release response, containing the full date (YYYY-MM-DD) a release is published so that I can estimate the probable next maintenance release date.

I'm fairly certain extra fields will just be ignored in all the places the updater server is polled so shouldn't introduce any sort of breaking change for older installations.

[AndyScherzinger]

looping in @Altahrim @skjnldsv @blizzz for the discussion

[blizzz]

Sounds like a neat idea 👍

I think this is also helps cases where people are stuck with an older version being blocked by old PHP versions – although this could be tackled differently. Perhaps hinting about an incompatible PHP version for a major upgrade could also be an addition.