User tests: Successful: Unsuccessful:
The manner in which updates check their supported platform is extremely subpar. The primary version attribute is only checked down to the minor version number (i.e. 3.4) which prevents using the advanced regex possibilities of the <targetplatform>
tag in an update XML file to match a specific version number. A "band-aid" style fix was applied in the manner of the min_dev_level
and max_dev_level
attributes which further demonstrates the weakness in this check.
This PR proposes to change the check to enable matching a full version number instead of only the major and minor versions.
Had 2.5 supported this, in extensions where versions older than 2.5.6 are unsupported, it would have been possible to use a regexp similar to 2.5.([6-9]|1[0-9]|2[0-8])
to not display updates to 2.5.0 thru 2.5.5 users. As 2.5 didn't even support the min_dev_level
and max_dev_level
attributes, users on those dated versions would always see an extension update that they could not install.
For general testing, the simplest tests are to apply the patch, install older versions of extensions which support Joomla's update platform (as Joomla won't display an update if you're on the latest version), and make sure those extensions still properly load updates. The language installer can be a good way to check this too.
For advanced use cases, developers are welcome to manipulate the Joomla version number (found in libraries/cms/version/version.php
and an update XML to create test cases where a regexp would or would not match a version number. Using my example above, 2.5.0 thru 2.5.5 and anything above 2.5.29 should not match but 2.5.6 thru 2.5.28 should.
Labels |
Added:
?
|
Category | ⇒ | Updating |
Right now, the internal check is a regex, so for B/C it has to stay that way. For example, the language XMLs use this to check against version 3.[012345]
, and that would break. I agree a version_compare
would be much simpler.
Could we maybe start a list of things (small/tiny things) somewhere, that we want to do for 4.0? Otherwise stuff like this would drop through and we have to drag this along until 5.0...
Could we maybe start a list of things (small/tiny things) somewhere, that we want to do for 4.0? Otherwise stuff like this would drop through and we have to drag this along until 5.0...
When we close PRs due to B/C but want to look at it again for 4.0, we already add the label "reevaluate for 4.0".
@test successful tested with an outdated german language file.
Easy | No | ⇒ | Yes |
@nikosdion Test please :-)
@test Successful test with Akeeba Backup Core and the German language pack.
Since this doesn't really affect b/c in any way I'd propose adding this to Joomla! 3.5 or, if the feature list is frozen, in 3.6.
Labels |
Added:
?
|
It's fine for 3.5
Status | Pending | ⇒ | Ready to Commit |
Status | Ready to Commit | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2015-07-12 17:26:25 |
Closed_By | ⇒ | Kubik-Rubik |
Labels |
Removed:
?
|
Shouldn't we simply support minimum requirements instead of complex regex version numbers? We could have a minimum version and then simply check with version_compare()...