PyO3 1.0 Stable version

[aviramha]

Hi All,
As discussed in #1965 , I'm creating a board to manage the release of the first stable major version of PyO3 - 1.0.
I'd like suggestions for issues that should be marked as required for first version, and nice to have.
After closing on the contents of the first release, we'll decide on a target release date and manage it using the new board.

Thanks for the help!

[aviramha]

Current suggestions by @birkenfeld:

• experimental: owned objects API #1308
• Migrating #[pyproto] to #[pymethods] #1884

[davidhewitt]

Digging through the issue tracker, here's my take on this:

Must-have

#1884 - removing #[pyproto] will simplify for users and reduce complexity of pyo3 for maintenance
#1056 / #873 - removing the GILPool reference layer will improve performance and make memory management easier in the Rust-embeds-python case
#211 - at least make a decision on this

Nice-to-have

#1714 / #834 / #417 - Enum support
#1709 - just needs MSRV bump first
#1647 / #1644 / #1637 / #1344 / #991 - clarity around subclassing design and functionality
#1358 - a way to avoid cloning Py<T> fields (maybe via #1089)
#1068 - immutable classes for simplicity and performance
#732 / #295 - exceptions almost work as #[pyclass] however theres a few bits of ergonomics to finish off. Then we can remove create_exception!.
#694 - having #[pymodule] mod foo { } instead of function may be a nice API improvement

I think the "must-have" bits, in particular the memory model, will take several release cycles to iterate and complete. What this tells me is that once I've finished working on the final bits of #1884 I should really look at picking up #1308 again.

Hopefully we can make progress on a lot of the nice-to-haves while the must-have pieces are resolved 😄

[birkenfeld]

As for #1709: With Debian bullseye released now, MSRV bump is possible (Debian is now at 1.48). (Ok, just saw #1782 already has this info. Bumps can happen in 0.16 then.)

[aviramha]

#211, I think it's nice to have but it's more of a syntactic sugar, and can be added after 1.0. I'd put it into nice-to-have.
I added and sorted the rest of the issues in the project with 2 labels: 1.0-must and 1.0-candidate (Must-have, nice to have)

[birkenfeld]

The thing with #211 is that while it's sugar, to introduce it in a non-breaking manner we'd have to keep the old names as well.

Although this kind of depends on our release cadence; if we release a new major version roughly every year (due to removing support for old Pythons), I don't mind that.

[aviramha]

That doesn't sound bad to me as it's quite a big change and people might have opinion on the new API.
I think minimum release cadence of 1 major per year is a good start.

[mejrs]

I think we also need to nail down any commitments we make as part of being stable.

For example I like tokio's wording

As part of the release, we are committing to providing a stable foundation for the ecosystem. We have no current plans for Tokio 2.0 and we commit to holding back on a Tokio 2.0 release for at least 3 years. We plan to maintain the Tokio 1.0 branch for a minimum of 5 years. Tokio will keep a rolling MSRV (minimum supported rust version) policy of 6 months. When increasing the MSRV, the new Rust version must have been released at least six months ago.

[davidhewitt]

Hmm interesting, I wasn't of the opinion that it's ok to call dropping support for end-of-life versions "non-breaking". If there's concensus amongst us that that is okay, then that would help us keep 2.0 release at bay for longer.

I do think that if we're going to commit to a multiple-year 1.0 release we will at least need to look at the 1.0-candidate issues and see if they might require breaking changes, and if so, whether they should be considered 1.0-must or whether we're ok waiting a few years for them.

[birkenfeld]

I think one breaking release per year is fine. We're neither an independent crate nor an ecosystem base like tokio (which must be very conservative to succeed), we're following a moving target. We're also much closer to the top of the crate dependency-chain, at least until there are dozens of crates like rust-numpy.

Together with a comprehensive migration guide similar to the ones we've already had, it's the better strategy to release more often, since it allows taking advantage of progress in CPython.

[davidhewitt]

👍 TBH that sums up nicely how I feel.

[aviramha]

I tend to agree with @birkenfeld