Skip to content
Permalink
Browse files

[Plugin installer] Follow up 54f312f and temporarily hardcode plugin …

…compatibility as 3.0
  • Loading branch information
borysiasty committed Dec 18, 2017
1 parent 10b37f3 commit 7c01b7e64780fe84732253ccc625f41e152a8539
Showing with 5 additions and 1 deletion.
  1. +5 −1 python/pyplugin_installer/installer_data.py
@@ -216,6 +216,7 @@ def urlParams(self):
# TODO: make this proper again after 3.0 release, by uncommenting
# the line below and removing the other return line:
# return "?qgis=%d.%d" % (int(v[0]), int(v[1:3]))
# TODO: Do the same for lines 469-472
return "?qgis=3.0"

# ----------------------------------------- #
@@ -465,7 +466,10 @@ def xmlDownloaded(self):
qgisMaximumVersion = qgisMinimumVersion[0] + ".99"
# if compatible, add the plugin to the list
if not pluginNodes.item(i).firstChildElement("disabled").text().strip().upper() in ["TRUE", "YES"]:
if isCompatible(Qgis.QGIS_VERSION, qgisMinimumVersion, qgisMaximumVersion):
# TODO: make this proper again after 3.0 release, by uncommenting the line below and removing the next line
# TODO: Do the same for lines 215-220
# if isCompatible(Qgis.QGIS_VERSION, qgisMinimumVersion, qgisMaximumVersion):
if isCompatible("3.0", qgisMinimumVersion, qgisMaximumVersion):
# add the plugin to the cache
plugins.addFromRepository(plugin)
self.mRepositories[reposName]["state"] = 2

4 comments on commit 7c01b7e

@m-kuhn

This comment has been minimized.

Copy link
Member

@m-kuhn m-kuhn replied Dec 18, 2017

Thanks for all the work you are doing on the plugin manager @borysiasty
Would it be possible to send them trought pull requests in the future, so travis and other devs have at least a short window to give feedback before it lands :)

@borysiasty

This comment has been minimized.

Copy link
Member Author

@borysiasty borysiasty replied Dec 18, 2017

@m-kuhn: for this particular commit it would be pointless, as I'm just working on a PR that reverts it ;) It's a fast fix for the tonight build - one string not covered by Travis' tests. In such cases I can rather skip fast fixes and keep things broken until me or someone else finds a time for implementing a long-time solution.

However, in general, do you mean pushing every single typo fix by a pull request? I fully appreciate this workflow, just don't notice we strictly follow it, so didn't want to clutter the PR queue with too obvious fixes. Speaking jokingly, if other devs keep breaking code I wrote without PRs, and I have to wait for reviewing my one-line fixes to their breaks, it will make QGIS defective for a longer time ;) But it's not this case, it was broken using a proper PR :)

@m-kuhn

This comment has been minimized.

Copy link
Member

@m-kuhn m-kuhn replied Dec 18, 2017

I have myself pushed some apparently easy fixes which ended up making trouble and had to be reverted, meanwhile breaking unit tests for other incoming pull requests and having people clicking around to find out that travis failed for unrelated changes.

So in short: yes, I think even for apparently trivial stuff it's good to send it through a pull request. Even better if you help keeping the PR queue decluttered by merging it yourself after a day with no or only positive feedback from other devs :)

@borysiasty

This comment has been minimized.

Copy link
Member Author

@borysiasty borysiasty replied Dec 18, 2017

@m-kuhn Unfortunately you're right ;)

Please sign in to comment.
You can’t perform that action at this time.