Use the builtin function `version_compare` to check an app's
compatibility with the available PHP version, instead of reusing
the `OC\App\CompareVersion::isCompatible` method which is intended
to compare Nextcloud versions. PHP version strings do not always
necessarily follow the simple Major.Minor.Patch format used by
Nextcloud and therefore cannot be properly compared by that method.
Signed-off-by: Damien Goutte-Gattat <dgouttegattat@incenp.org>
Apps might increase the minimum php version requirement, in which case
an update could break the app or even the whole instance. We must not
install those releases, or better, don't even show them for
update/installation. This extends the app fetcher code to filter out the
releases that are not installable.
The filter respects minimum and maximum requirements. E.g. apps that are
still only released for php7.3 won't show up for php7.4 instances. This
behavior is new but if an app lists an explicit version requirement,
then we ought to repect that.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
To continue this formatting madness, here's a tiny patch that adds
unified formatting for control structures like if and loops as well as
classes, their methods and anonymous functions. This basically forces
the constructs to start on the same line. This is not exactly what PSR2
wants, but I think we can have a few exceptions with "our" style. The
starting of braces on the same line is pracrically standard for our
code.
This also removes and empty lines from method/function bodies at the
beginning and end.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
If an app requires a specific minor or path level server version,
the version_compare prevented the installation as only the major
version had been compared and that checks obviously returns `false`.
Now the full version is used for comparison, making it possible to
release apps for a specific minor or patch level version of Nextcloud.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
When in the upgrade process the version in the config is still the old
version. (Since we only upgrade it after the upgrade is complete).
However the app list fetched from the appstore must be the new list.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
* If the ETag if present store it
* If a stored ETag is present then pass it along (with the original
response) to get
* Add tests
* Added files to classmap
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
As SemVer can be used apps could define a release like "10.0.0-alpha". This is something that we don't support at the moment in the server and we should filter all prereleases.
Ref https://github.com/nextcloud/server/pull/2307#issuecomment-262911588
Signed-off-by: Lukas Reschke <lukas@statuscode.ch>
The current implementation when fetching apps from the appstore is to assume that the first element is the newest version, this is now always applicable and leads to the fact that for some apps (e.g. nextant) the newest version is not delivered. This can be easily tested by comparing the version of the downloaded Nextant version.
This change will loop over all releases delivered by the appstore and chooses the newest compatible one. While not the cleanest solution, it does its job.
Most of the code are actually unit tests. Whereas I have copied the whole original response from the appstore and also have performed the transformation. So that's why the diff looks so huge.
Signed-off-by: Lukas Reschke <lukas@statuscode.ch>