The overloaded stable release channel #1051
Description
Our docs reference the following stable (maintained) release versions:
- latest
- previous
- last supported
e.g. currently that is:
- v29
- v28
- v27
All three of these are simultaneously offered via the stable release channel.
This makes the Updater non-deterministic, adds to an admin's cognitive load, and creates marketplace confusion even though we're putting extra resources into maintaining multiple stable majors simultaneously within the project - e.g.
- if v30.0.0 is published before v29.0.10 then admins that check Admin Overview page will be offered v30.0.0 before v29.0.10 while those that check after v29.0.10 is published will be offered v29.0.10
- if an admin is running the latest v28 maintenance release while it's still actively maintained, they're still offered v29.0.0 at release time and it's not illogical for them to assume they need to update to v29.0.0 to receive the latest security and bug fixes even though that isn't actually true nor does being offered it automatically indicate v28 has reached end-of-life
- confusion about which releases are actually still receiving maintenance updates, when they need to jump to the next major, etc.
It would be kind of cool if an admin could set their release channel to last supported or previous or latest depending on their preferences. One approach to accomplishing this would be splitting the stable release channel up to more logically map to what it really contains today.
Technically this could be facilitated without splitting the stable release channel but it would require more complicated logic in the Updater drawing from limited information. Also, some of the above confusion can be reduced by improving how we present update paths in the Updater. I think we should do that too, but even that would be made easier by splitting the stable release channel or something similar.