When multiple possible upgrades are available for the system, Software only offers one. And which one it is isn't decided by any kind of sensible heuristic, but purely based on the order of the list the plugin provides.

To reproduce:

1. Install Fedora 23
2. Edit fedora.json and mark Fedora 25 as 'Active' (Fedora 24 should already be Active)
3. Log out and back in to empty caches
4. Run Software and do a refresh on the Updates screen
5. Note that only Fedora 24 is shown
6. Edit fedora.json and move Fedora 25 down so it's under Fedora 24
7. Log out and back in again
8. Refresh Updates again
9. Now see that only Fedora 25 is shown

I've poked around in the code and this is my understanding of the behaviour.

 gs-shell-updates.c `gs_shell_updates_load` asks (via several intermediate plugin loader steps) the plugin for the result of `gs_plugin_add_distro_upgrades` (which is a `gs_app_list` of 'gs_app' instances, each representing a single available OS release), then it feeds that list to `gs_shell_updates_get_upgrades_cb`, which just takes the first entry from the list and feeds that into the 'upgrade_banner' bits, which are all set up to assume precisely *one* upgrade banner.

So we know that it's definitely only ever going to offer one upgrade. That seems fairly clear.

As for the ordering, well...as mentioned, the list of available upgrades is a `gs_app_list`. `gs_plugin_add_distro_upgrades` from the Fedora just takes the list of releases from the fedora.json file - which itself is a download of https://admin.fedoraproject.org/pkgdb/api/collections/ - and iterates over the 'collections' (releases) in that file, adding each one that meets its conditions to the list by calling `gs_app_list_add`.

The order of the entries in fedora.json is basically random - they're grouped by status, but within the status groups the order is not sensible, e.g. 26 comes before 25 and the recent stable releases go 20, 19, 23, 22, 21, 24. So we can't rely on that list being in a sensible order.

Now I'm no C expert, but as best as I can tell, a `gs_app_list` is just a structure which provides both an array and a hash of pointers to the same bunch of 'app' objects; the hash keys are the app ids. But we're not even using the hash, here, just the array. When you call `gs_app_list_add` it just stuffs the pointer onto the end of the array.

`gs_shell_updates_get_upgrades_cb` just asks for `gs_app_list_index (list, 0)`, which is the first item in the array. So I'm pretty sure we just wind up taking whichever is the first release listed in fedora.json that meets all of the requirements of `gs_plugin_add_distro_upgrades`.

There is a fun postscript here, which is that the GNOME 3.20 behaviour - which is important, here, because 3.20 is what's in Fedora 23, and we're about to release Fedora 25 - is almost the same, only backwards.

The 'app list' stuff was rejigged somewhere between 3.20 and 3.22. In 3.20, the list is just a GList, and gs-app-list.c doesn't exist. When adding the 'app' for a release to the list, `gs_plugin_add_distro_upgrades` calls `gs_plugin_add_app` (from `gs-plugin.c`), which does this:

	*list = g_list_prepend (*list, g_object_ref (app));

so it stuffs the entry onto the *start* of the list, not the end, as 3.22 does with its array.

So that means that in 3.20 (and hence Fedora 23), Software will offer the *LAST* release listed in fedora.json that meets all of the requirements of `gs_plugin_add_distro_upgrades`, rather than the *first*.

Either way, the upshot of this is that right now we have literally no way of knowing whether, when Fedora 25 is released, Software will offer Fedora 23 users an upgrade to 24 or 25. It simply depends on where Fedora 25 happens to show up in the 'collections' list in https://admin.fedoraproject.org/pkgdb/api/collections/ . If it shows up *after* Fedora 24 in that list, Software will start showing Fedora 25 as the available upgrade for Fedora 23 users. If it shows up *before* Fedora 24, Software will keep offering Fedora 24 as the available upgrade.

The interesting question here is, what is our *intended* behaviour? Clearly depending on the order of a list whose order is random is silly, but given that we'll change the behaviour, what do we change it to?

Do we want to offer multiple upgrades when multiple higher non-EOL releases are available?

If we only offer one, do we always offer the latest release available? Or do we always offer N+1?