-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix min_qg_version query in plugins.xml #224
Fix min_qg_version query in plugins.xml #224
Conversation
Codecov Report
@@ Coverage Diff @@
## master #224 +/- ##
==========================================
+ Coverage 37.27% 37.55% +0.27%
==========================================
Files 77 85 +8
Lines 3364 3672 +308
==========================================
+ Hits 1254 1379 +125
- Misses 2110 2293 +183
Continue to review full report at Codecov.
|
LGTM, but wait for Tim's approval too. @timlinux will there be any problems on the qgis side? |
@sumandari looking at your fix: will it be OK to always add .99 ? Should it not depend on the use of 'minimum_version' and 'maximum_version'? In the case of somebody telling: minimum version = 2.2 they probably mean: that you should at least have 2.2.0 (and not 2.2.99)? But maybe this does not affect plugins.qgis.org... ? Another observation: am I right that we are not using some kind of module/code for this, but we are parsing version numbers ourselves? See #236 (comment) |
Thank you for your feedback @rduivenvoorde. What I proposed in my quick fix was with an assumption that the version of QGIS will never have 3rd versioning segment (patch) in this repo.
But indeed that's not a good approach for permanent fix. I think #236 (comment) is better and looks promising. |
@sumandari I updated the #236 (comment) example. I think this could indeed be very handy and helpfull. It is apparently used for the same purpose in pip to determine the compatibility of modules from the requirements.txt. See more info in the comment. Thanks for fixing this!! |
Thank you for the update @rduivenvoorde. I'm still figuring out how to change the char type record (min_qg_version) as a version instance so that it can be filtered directly in django query QGIS-Django/qgis-app/plugins/views.py Line 927 in d0cde22
|
Hi @rduivenvoorde, from your example so we can expect this case :
Because currently the api only accepts two parts numbers : XX.XX |
Hi @dimasciput, not sure if your comment is a question or not. But I think your scenario is indeed a problem (at this moment?). As apparently the plugin author want's to be able to set a very precise 'patch'-version to it's plugin... And that will indeed not work because QGIS only requests plugins with a major.minimal version number So isn't it the only solution:
@sumandari so I think if we take the second solution (which is good enough), then this PR is almost the final solution? Except that in this part: you should also 'patch/fix' the major.minor of max_qg_version? @suricactus what do you think? |
If we add .99 for filtering max version, it will not include the major.minor with lower patch version |
@sumandari I'm not following exactly... but what I thought:
|
I do agree with your proposal, except the part saying "qgis version will never have a patch-part". I believe QGIS should start sending the patch version too. This should not break anything, or at least nothing worse than now. The plugin can have either major.minor in their metadata (x.y), or major.minor.patch (x.y.z). This goes for both min and max QGIS version. On the other hand, for backwards compatibility, QGIS can send either major.minor (a.b) or the future versions should send major.minor.patch (a.b.c) Minimum version check:
Maximum version check:
It is predictable and works as most package manager already work. For example a plugin with |
Updated PR 4cd2894:
Test against max_qg_version For test against min_qg_version please see: #224 (comment) |
LGTM @sumandari but:
|
@timlinux at the moment, we don't have a staging server for QGIS-Django. Could you please advise where we can deploy and test it? |
Hi, just discovered this PR.
I think so, too (see #222 (comment) for an issue related to this) and opened qgis/QGIS#47907 for the QGIS part to send the patch version. There are quite some plugins already which are using the patch version for min/max QGIS version. If you agree, we would need also the api to accept the full version (three part number)
e.g. https://plugins.qgis.org/plugins/plugins.xml?qgis=3.16.14 |
So what blocking us moving forward is the question whether a staging server is available? |
@pathmapper we are busy setting up a staging server. |
Merging this PR to develop branch and then will deploy it to staging. |
Hi @pathmapper , we have set up the staging server here https://staging.plugins.qgis.org/. This PR is deployed to the staging server. |
What is the current status here? Are there any issues which are blocking this for production deployment? |
* fix min_qg_version query * added 0 patch value for qgis version against max_qg_version * only add patch if it has major.minor version
* Fix min_qg_version query in plugins.xml (#224) * fix min_qg_version query * added 0 patch value for qgis version against max_qg_version * only add patch if it has major.minor version * Update docker-compose and dockerfile * Update nginx configuration * Update smtp * Add celery beat * Add feedjack update celery task * Add metabase configuration * Update test.yaml * Add test docker-compose Co-authored-by: sumandari <sumandari@kartoza.com>
@dimasciput @timlinux currently for this patch the staging server isn't available anymore and it hasn't reached the production server. Do you have any information about what is planned regarding implementing this for production? Asking because the corresponding PR in the QGIS repo qgis/QGIS#47907 is marked as stale regularly since months and I'm unsure wether it should be kept open or closed... |
Hi @pathmapper , it seems this only merged to develop branch, I will create a PR against master and then deploy it. I will let you know when it's on production. |
* fix min_qg_version query * added 0 patch value for qgis version against max_qg_version * only add patch if it has major.minor version
* fix min_qg_version query * added 0 patch value for qgis version against max_qg_version * only add patch if it has major.minor version
sorry @pathmapper for late reply, but this has been deployed to production. |
@dimasciput no worries, thanks for the info! https://plugins.qgis.org/plugins/plugins.xml?qgis=3.26.3 gives But for staging it's working again Could you please have a look, why it's not working for the production server? |
@pathmapper yes this wont work because the production pre-generated the plugins xml, and the staging doesn't do that. Please check previous discussions #224 (comment) |
Thanks for the backgound @dimasciput.
Does this happen with every plugin upload?
OK, I see. If we want to proceed with qgis/QGIS#47907 : Once this PR is merged, QGIS will start to send the patch number so this could happen at the earliest with 3.28.1. Could this be addressed somehow? |
Hi @sumandari, @dimasciput, @pathmapper, was the issue reported at https://lists.osgeo.org/pipermail/qgis-developer/2022-November/065249.html triggered by this PR?
|
@agiudiceandrea hi, let me check it now. |
@agiudiceandrea yes you are right, I have reverted this PR and will be doing more testing on staging again. Sorry for the incident. |
the plugins should be updated now |
@dimasciput thank you very much! |
* Upgrade the stack from Django 2.2 to 3.2 (#233) * Upgrade the stack from Django 2.2 to 3.2 * Upgrade pip as well when installing Co-authored-by: Dimas Ciputra <dimas.ciputra@gmail.com> * Update docker compose (#256) * Fix min_qg_version query in plugins.xml (#224) * fix min_qg_version query * added 0 patch value for qgis version against max_qg_version * only add patch if it has major.minor version * Update docker-compose and dockerfile * Update nginx configuration * Update smtp * Add celery beat * Add feedjack update celery task * Add metabase configuration * Update test.yaml * Add test docker-compose Co-authored-by: sumandari <sumandari@kartoza.com> * Fix docker-compose and dockerfile * Init starting docker dev environment * Fixing docker container conflict, updating whoosh * Update testfiles and feedback test * Update dockerfile for dev and prod * Use main branch for whoosh in requirements * Django 4 update: Requirements, dockerfile and docker-compose * Django 4 update: fixes for ifequal, ugettext_lazy, django.conf.urls.url occurences * Django 4 update: Fix deprecated readfp * Django 4 update: update dbrestore in Makefile * Django 4 update: Get static, media and backup volumes from the environment variable * Django 4 update: Use solr thumbnail default engine * Django 4 update: Fix Django warnings * Django 4 update: fix depecated tests, new migrations * Django 4 update: Update django unit tests * Django 4 update: Add email environment variables * Django 4 update: Nginx and uwsgi updates * Django 4 update: Refactoring dockerfile * Update makefile to use new docker compose * Django 4 update: Specify devweb container_name, fix typo * Use existing nginx configuration * Add DEFAULT_PLUGINS_SITE to environment variables * Add nginx dev and prod configuration files * Django 4 update: Generate a .env file in GH actions * Django 4 update: Fix typo in Makefile * Django 4 update: Use updated docker compose in test.yaml * Django 4 update: Certbot service and SSL configuration * Add a http configuration for Nginx * Django 4 update: add SSL cert renewal script * Redirect http to https --------- Co-authored-by: Étienne Trimaille <gustrimaille@yahoo.fr> Co-authored-by: Dimas Ciputra <dimas.ciputra@gmail.com> Co-authored-by: sumandari <sumandari@kartoza.com>
This is to fix #223
Proposed solution:
Add the 3rd segment with max number as a patch number version (eg. 3.6.99) in
qgis
version against the query, so that the PluginVersion with minimum qgis version 3.16.x will be available in QGIS 3.16