<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 7, 2023 at 12:30 PM Jeremy Stanley <<a href="mailto:fungi@yuggoth.org">fungi@yuggoth.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2023-03-07 11:19:26 -0500 (-0500), Corey Bryant wrote:<br>
[...]<br>
> The current upper-constraint for cryptography is 38.0.2, but the<br>
> various requirements.txt min versions are much lower (e.g.<br>
> keystone has cryptography>=2.7). This is likely to lead to patches<br>
> landing with features that are only in 38.0.2, so it will likely<br>
> be difficult to enforce min version support. But perhaps a stance<br>
> toward maintaining compatibility could be established.<br>
[...]<br>
<br>
While introducing specific tests for this would not be trivial,<br>
maybe it's one of those situations where we try to avoid breaking<br>
compatibility with older versions and don't reject patches when<br>
people find that something has inadvertently started depending on a<br>
feature only available in the Rust-based builds?<br>
-- <br>
Jeremy Stanley<br></blockquote><div><br></div><div>I'd be okay with an approach like this. Would this need to be formally adopted by the TC?<br></div><div><br></div><div>Corey<br></div></div></div>