Open joshtrichards opened 5 months ago
Since we sometimes fix migration issues, it's intended that you can only update from the latest patch version to the next major.
But I agree that availability of updates and clearer maintenance state would be helpful.
Our docs reference the following stable (maintained) release versions:
e.g. currently that is:
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.
It would be kind of cool if an admin could set their release channel to
last supported
orprevious
orlatest
depending on their preferences. One approach to accomplishing this would be splitting thestable
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 thestable
release channel or something similar.