Merge in backend-explicit-tests

[mattsb42-aws]

Ok, now the big one.

I am intentionally merging from the mpdavis fork to verify that nothing was changed on my end. All of these changes have been handled through PRs into the mpdavis/backend-explicit-tests dev branch, terminating in a final merge of master into backend-explicit-tests.

I also have a readme change that I want to make to better frame these changes once they are released, but I'll get that into master after this.

Open question to the maintainers @zejn @mpdavis : what version will the first release to incorporate these changes be? I don't see a versioning policy explicitly stated anywhere, and as noted in #99 there aren't currently any release notes that I could look though to infer a versioning policy. Would the next release be a good time to address both of those gaps?

[codecov]

Codecov Report

Merging #129 into master will increase coverage by 1.92%.
The diff coverage is 94.94%.

@@            Coverage Diff             @@
##           master     #129      +/-   ##
==========================================
+ Coverage    94.6%   96.52%   +1.92%     
==========================================
  Files          13       14       +1     
  Lines        1000     1065      +65     
==========================================
+ Hits          946     1028      +82     
+ Misses         54       37      -17

Impacted Files	Coverage Δ
jose/backends/cryptography_backend.py	98.11% <100%> (+1.22%)	⬆️
jose/backends/rsa_backend.py	96.5% <100%> (-0.7%)	⬇️
jose/backends/__init__.py	100% <100%> (+63.63%)	⬆️
jose/backends/_asn1.py	89.47% <89.47%> (ø)
jose/backends/pycrypto_backend.py	95.76% <92.3%> (-0.61%)	⬇️
... and 1 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update cc710e0...64cb29f. Read the comment docs.

[blag]

I would like to make a release that includes these changes (as well as your incoming readme PR), and my Ed25519 support PR once that is merged (I’ll have time to finish that up later this week). So in terms of time, I would estimate a release within 1-2 weeks, if @zejn doesn’t have any objections. I’ll also triage some of the outstanding PRs and issues a bit more later this week so they make it into the next release.

In terms of a versioning method, I haven’t taken a look at previous release version strings, but I imagine that SemVer is probably a good default versioning scheme.

Finally, since @zejn is a more familiar with your previous PR I’ll leave this for him to merge. Thank you for your contributions so far and keep up the good work both of you!

Ninja edit: changelog -> readme

[zejn]

I don't think there's currently an explicit versioning policy. Whenever there were bigger changes, there was a major version increase.

I don't think current changes need a major version increase, I'd make it a 3.1. Most of the development was done in cleaning up the backends, and if some code is relying on something specific in the backend, which is not part of the API, then that's bound to break sooner or later.

The priority of the backends was changed, yes, but that should not make an existing installed backend unimportable and nonfunctional. If that happens, then it's a bug, but not an API breakage.

I'd also like to see issue #112 fixed before the next release and PR #100 has seen a lot of work and is nearing readiness.

I would like to hear what @mpdavis or @blag think about this though.

[zejn]

This looks good and seems we agree with @blag on a rough release schedule.