adding-more-native-to-your-react-native-app
adding-more-native-to-your-react-native-app copied to clipboard
alloy
Bump decode-uri-component from 0.2.0 to 0.2.2 in /demo59
Bumps decode-uri-component from 0.2.0 to 0.2.2.
Release notes
Sourced from decode-uri-component's releases.
v0.2.2
- Prevent overwriting previously decoded tokens 980e0bf
https://github.com/SamVerschueren/decode-uri-component/compare/v0.2.1...v0.2.2
v0.2.1
- Switch to GitHub workflows 76abc93
- Fix issue where decode throws - fixes #6 746ca5d
- Update license (#1) 486d7e2
- Tidelift tasks a650457
- Meta tweaks 66e1c28
https://github.com/SamVerschueren/decode-uri-component/compare/v0.2.0...v0.2.1
Commits
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.
Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)@dependabot use these labelswill set the current labels as the default for future PRs for this repo and language@dependabot use these reviewerswill set the current reviewers as the default for future PRs for this repo and language@dependabot use these assigneeswill set the current assignees as the default for future PRs for this repo and language@dependabot use this milestonewill set the current milestone as the default for future PRs for this repo and language
You can disable automated security fix PRs for this repo from the Security Alerts page.
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "Published by a pub.dev verified publisher"){kind=small}
On 10/04/2016 18:28, Dave Jones wrote:
While I'm spamming the repo with tickets (sorry!), if you need any help doing Rapsbian packaging, let me know - I've got some fairly good Makefiles and configurations that make the process about as painless as I can (which include building py2 and py3 packages, plus offline docs packages).
Thank you; I will definitely be taking you up on that later, especially if it eases some of the pain which @ntoll identified in building the ZeroMQ dependency.
Just checked what versions zmq is packaged at on Raspbian - currently python-zmq is version 14.4 of pyzmq on Raspbian Jessie, relying on libzmq 4.0.5, so not the latest version but not horrifically ancient. However, Raspbian Wheezy is python-zmq 2.2, relying on libzmq 2.2, so that really is pretty ancient.
In other words: your call if you want to support Raspbian Wheezy at this point, but it'd mean ensuring all your zmq stuff is compatible with that back-level version for as long as you want to support Wheezy. In gpiozero, we're supporting Wheezy for the time being, but that's largely because we've managed to eliminate damned near all our mandatory dependencies (or at least make them optional by implementing a software variant of SPI, for example). Hence, it's a minimal burden in our case but I imagine it may be different for nw0.
On 10/04/2016 19:54, Dave Jones wrote:
Just checked what versions zmq is packaged at on Raspbian - currently python-zmq is version 14.4 of pyzmq on Raspbian Jessie, relying on libzmq 4.0.5, so not the latest version but not horrifically ancient. However, Raspbian Wheezy is python-zmq 2.2, relying on libzmq 2.2, so that really is pretty ancient.
Thanks for doing the check. If you haven't, feel free to peruse #issue3 where @ntoll and I go to and fro on the dependency issue. I'm just fearful of that old adage: those who ignore <toolX> are doomed to reimplement it poorly!
I'll give this some more thought.
Now Raspbian is on stretch - is this something we might find a moment to hack on a bit at PyconUk?
