Is your feature request related to a problem? Please describe.

Because updating from anything else than the latest 4.4 to 5.0 is not supported, we make sure that this is fulfilled with the targetplatform in the updatesite's details XML file when using Live Update, but it can be circumvented by using the Upload & Update method.

That we only support updating from the latest 4.4 version to 5 was a deliberate decision, and it is the same as it was with 3.10 and 4.

Describe the solution you'd like

We have to find a way to block unsupported updates with Upload & Update, too, preferably without the need to change a hard-coded version number with every new 4.4.x patch version.

It has to work offline because Upload & Update has to work offline, too, so we can't use information from the update site.

Offline means the webserver cannot reach the internet, only an intranet where you work on the client with your browser.

We should do that also in 4.4 to make sure we update from the latest 3.10. The version numbers in the title are for 5, but that's only the example.

A possible solution would be following:

In the 5.0-dev branch, we extend the build.php script so that it fetches the latest release version number of the previous major release either from GitHub API or from git tags.

This would currently be 4.4.0-beta1 for the 5.0-dev branch or 3.10.12 for the 4.3-dev and 4.4-dev branches.

Alternatively, when being offline and not having fetched latest tags with git, it should be possible to pass that version as a call parameter to the build.php script.

This would also be necessary when the order of release does not match, i.e. a 5.0.x is released and the 4.4.y which shall be released at the same day is released a bit later. When running the build.php for 5.0.x, it would find 4.4.(y-1) as the latest 4.4, which is wrong.

This previous major latest version number is saved in a file (text, xml, whatever), and this file is included in the update zip and whatever else packages.

The Joomla Update Component on 4.3 and 4.4 can read that version from that file when unpacking the 5.x update package and block the update if the current version is smaller than the version in that file (using version_compare).

In detail the content of that file can be read from the zip before the zip is unpacked. It costs a few microseconds but that's not a thing.

Alternatively, the version number can be part of the name of a file in a particular folder where only that one file matching a name pattern exists. Then we can get the version just from the toc of the zip without really reading any file content.

Of course opinions and suggestions are welcome.

Additional context

There are two reasons why updating to 5 from anything else than the latest 4.4 version does not work, i.e. results in a more or less inconsistent or broken site.

1. The update SQL scripts from 4.4 will not be there and so not run when updating directly from 4.3.x to 5. This is currently only one update SQL script, but it might become more during the live time of 4.4, and the more it becomes, the more the database will be inconsistent or broken after the update

2. The same applies to deleting obsolete files and folders on update. Things which would be deleted when updating from 4.3 to 4.4 before updating to 5 will not be deleted when updating directly from 4.3 to 5. As we have restructured all these modules and plugins in 4.4 and the deletion of the files at the old locations will not take place, I don't really know what happens when the autoloader file is rebuilt, if it will contain entries for the old plugin locations.

The same reasons apply of course to 4 and 3.10.12, only that the plugins were not all restructured.