Skip to content

Remove upper bound on cryptography version #777

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

Merged
merged 1 commit into from
Oct 2, 2021

Conversation

riconnon
Copy link
Contributor

@riconnon riconnon commented Oct 2, 2021

Cryptography has adopted a firefox-style versioning system where new
feature releases always have new major versions even if they don't have
backwards incompatible changes. This means that an upper bound on the
dependency does not make sense.

Cryptography has adopted a firefox-style versioning system where new
feature releases always have new major versions even if they don't have
backwards incompatible changes. This means that an upper bound on the
dependency does not make sense.
Copy link
Contributor

@auvipy auvipy left a comment

Choose a reason for hiding this comment

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

what if version 4 break compatibility?

@riconnon
Copy link
Contributor Author

riconnon commented Oct 2, 2021

@auvipy
the cryptography project never used semver. They made no guarantee of compatability in "minor" versions, only "bugfix", so for example 3.5.0 was not guaranteed to be compatible with 3.4.x
cryptography has just released the latest version 35.0.0 (which you may have expected to be 3.5.0) which is "mostly" compatible with 3.4.x except for a couple of things relating to x509 parsing

Full details here: https://cryptography.io/en/latest/api-stability/#version-35-0-0

@auvipy auvipy merged commit 354d435 into oauthlib:master Oct 2, 2021
@riconnon riconnon deleted the cryptography-versioning branch October 2, 2021 19:28
@riconnon
Copy link
Contributor Author

riconnon commented Oct 2, 2021

@auvipy
This will likely start to present a fairly major inconvenience to your users once other dependencies start wanting the newer cryptography releases.
What's your typical release cycle? When could we expect a release version including this change?

@graingert
Copy link

I think blocked on #766 ?

@auvipy auvipy added this to the 3.2.0 milestone Dec 13, 2021
payerle added a commit to payerle/spack that referenced this pull request Jan 25, 2022
py-cryptography now increments major versions even if there are
no backwards incompatible changes, so oauthlib package dropped the
upper limit on py-cryptography versions.

See e.g. oauthlib/oauthlib#777
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy