release: 0.15.0

[davidhewitt]

Closes #1921

As per that #1921, I think there's plenty of changes now accumulated which would be worth releasing as 0.15.

There might be a couple of extra fixes which merge (such as updates for PyPy), and maybe experimental versions of sequence / gc / buffer protocols if I get a chance to implement them.

I'll put live on Saturday if I hear no reason to delay.

@indygreg - for PyOxidizer would it be helpful if I produced a 0.15.0-rc.1 release for you to use before then?

[indygreg]

For testing PyOxidizer, I can point Cargo at a Git branch/commit for testing. As long as I can get CI passing against what will become 0.15.0, I should be good. Thanks for thinking about me!

I've already started testing the release-0.15 branch and found a regression, which #1950 should fix.

[indygreg]

Looks like PyOxidizer's port to PyO3 0.15 is trivial: https://github.com/indygreg/PyOxidizer/tree/pyo3-015. Aside from the missing memory API symbols, this release/branch seems to look great from PyOxidizer's perspective! The port was pretty trivial and all issues were identified from compiler errors. And all compiler errors were from changes captured in the changelog.

[alex]

pyca/cryptography is green with 0.15 (pyca/cryptography#6472)

[davidhewitt]

From the PRs I have seen updating to this release candidate, I would like to make a decision on #1957 which reverts the breaking change around PyErr::fetch before making the final release.

[mejrs]

From the PRs I have seen updating to this release candidate, I would like to make a decision on #1957 which reverts the breaking change around PyErr::fetch before making the final release.

How many people use it directly and how do they use it?

Just scrolling through greg's PR, something like PyErr::fetch() -> Result<(), PyErr> also makes some sense.

For example, that allows writing things like:

if !unsafe { pyffi::PyErr_Occurred() }.is_null() {
    return Err(PyErr::fetch(py).expect("error should have occurred"));
}

as

PyErr::fetch(py)?;

I likePyErr::fetch() -> Option<PyErr> as well, it does seem to map better to the underlying api as you've noted.

[mejrs]

Let's try to find some prior art:

https://doc.rust-lang.org/std/net/struct.TcpStream.html#method.take_error (the other stream types in std are similar)

https://docs.rs/async-std/1.10.0/async_std/io/struct.Error.html#method.last_os_error

https://docs.rs/os_error/0.1.0/i686-unknown-linux-gnu/os_error/struct.OsError.html#method.last_os_error

[davidhewitt]

(Thanks for the comments, continued on #1957)

[davidhewitt]

#1957 is merging soon, I will rebase this PR and prepare the release tomorrow.

[davidhewitt]

Rebased on main and intend to release this evening. Thanks for patience everyone.

[davidhewitt]

Release is live!