Skip to content

Commit

Permalink
[Plugin installer] Follow up 54f312f and temporarily hardcode plugin …
Browse files Browse the repository at this point in the history 
…compatibility as 3.0
  • Loading branch information
@borysiasty
borysiasty committed Dec 18, 2017
1 parent 10b37f3 commit 7c01b7e
Showing 1 changed file with 5 additions and 1 deletion.
6 changes: 5 additions & 1 deletion python/pyplugin_installer/installer_data.py
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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"

# ----------------------------------------- #
Expand Down Expand Up @@ -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
Expand Down

4 comments on commit 7c01b7e

@m-kuhn
Copy link
Member

@m-kuhn m-kuhn commented on 7c01b7e Dec 18, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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
Copy link
Member

@m-kuhn m-kuhn commented on 7c01b7e Dec 18, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@m-kuhn Unfortunately you're right ;)

Please sign in to comment.