-
Notifications
You must be signed in to change notification settings - Fork 795
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
release: 0.13.2 #1400
release: 0.13.2 #1400
Conversation
I was thinking #1393 would be merged after this release since 0.13.2 would unblock the first public release of pyo3-asyncio. There are a few API doc links I'd like to add in there that would only be available after docs.rs generates them. I could probably guess at what they would be in the meantime though, so it's up to you guys. |
I'm flexible. The reason I'm thinking that it would be nice to merge the guide entry first, is then users who will be reading the guide at |
I'm ok with merging it for |
Still waiting on the other PRs, which are steadily moving forward. Also the fix in #1405 seems worth including. I'll rebase this in a few days once they're all ready. |
The other PRs have now been merged; I'll rebase and release tonight unless I hear a reason not to! |
I request #1420 to be decided for this release. |
Agreed. The release can wait a little longer, I'm sure 😅 |
f120eb4
to
da37e39
Compare
Rebased; I'll release this tomorrow evening unless again there's reasons to wait. I'll probably merge and rebase on #1422 before doing so. I also updated the release notes with more contributors and to mention the MSRV lowering. |
The OpenSSL team will publish a security release on Tuesday 16th February 2021. PyCA Cryptography follows OpenSSL and releases new builds on the same day. Would it be possible to get a new release of pyo3 out before Tuesday? PyCA Cryptography could then bump pyo3 version for the upcoming release and benefit from @birkenfeld's PR #1420. This would make Debian stable and Alpine 3.12 users happy. CC: @alex @reaperhulk |
FWIW, I see no need for pyo3 to schedule a release around OpenSSL. We
can do two releases of pyca/cryptography, version numbers are free, as
I'm so often reminded.
…On Fri, Feb 12, 2021 at 11:31 AM Christian Heimes ***@***.***> wrote:
The OpenSSL team will publish a security release on Tuesday 16th February 2021. PyCA Cryptography follows OpenSSL and releases new builds on the same day.
Would it be possible to get a new release of pyo3 out before Tuesday? PyCA Cryptography could then bump pyo3 version for the upcoming release and benefit from @birkenfeld's PR #1420. This would make Debian stable and Alpine 3.12 users happy.
CC: @alex @reaperhulk
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
--
All that is necessary for evil to succeed is for good people to do nothing.
|
da37e39
to
190eb72
Compare
👍 I think this release now has everything it needs, so I'm releasing shortly. (Once CI is green.) |
Thanks 🎉 |
cc @kngwyu
This is the last release I think we need to make for the 0.13 series before we merge a number of breaking changes and start developing for 0.14. We already have breaking changes #1354 #1391 and #1398 waiting to be merged, as well as many
#[deprecated]
methods we could begin cleaning up.Making this release will fix the issues with finalization which is blocking
pyo3-asyncio
from making a first release.I'll try to release this on Tuesday if I don't hear otherwise. Though I think it'd be nice to merge #1393 and #1379 before we release this, so I might wait if needed.
I suggest the following release text:
This release contains small improvements over PyO3 0.13.1. The minimum supported Rust version has been lowered to Rust 1.41. A
serde
feature has been added which provides implementations ofSerialize
andDeserialize
for types inside thePy<T>
smart pointer.Of note is that this release disables automatic finalization of the Python interpreter at program exit for Rust binaries embedding the Python interpreter. This was found to cause a number of issues with C extensions such as Tensorflow and Scipy which were sensitive to the deinitialization order. For the vast majority of users this should cause no impact or fix a number of problem cases. For the minority who did depend on finalization, the unsafe method
with_embedded_python_interpreter
has been added to manually control the interpreter lifecycle.For full details of all changes, see the CHANGELOG.
Thank you to everyone who contributed code, documentation fixes, design ideas, bug reports, and feedback. The following users' commits are included in this release:
@alex
@awestlake87
@birkenfeld
@cfbolz
@daniil-konovalenko
@davidhewitt
@decathorpe
@ijl
@kangalioo
@kngwyu
@lazka
@nw0
@tdamsma