First 1.x version (Stable API)

[aviramha]

Hi!
I have been following and working with PyO3 for quite a time now, and I have noticed that PyO3 exists for more than 4 years without releasing a major version (1.x) which if followed by semver, will be stable API.
I was wondering what's the status - do we have some tracking or milestones that are desired before releasing a 1.x version? I think that PyO3 is in state that it should graduate to its first major version, and it will help it accelerate and grow better - many users can be scared by 0.x versions.

[birkenfeld]

Well, there are several things that are in the works, so it would be a shame to not have them in the stable 1.0. The ones I immediately think of are:

• new owned object API (experimental: owned objects API #1308) and possible rename of PyAny, PyObject
• finishing the move of protocols to pymethods (Migrating #[pyproto] to #[pymethods] #1884)

But I think at least a tracking issue for 1.0 would be nice, to have those plans visible, and also to find a cut-off at some point. We're obviously not committing to staying on 1.x forever, like Rust does, so I agree that 1.0 sooner rather than later is preferable.

[aviramha]

Thanks! I wasn't actually imagining that 1.x should be released right away, rather really have some more concrete plan we can work toward and make it happen! :)

[davidhewitt]

Agree with @birkenfeld's answer. 👍 I have wondered about 1.x myself and agree it would be desirable to aim to be there sooner rather than later.

I think the main question is does 1.0 signify stability or production readiness. IMO PyO3 is already very production ready for writing extension modules. The Rust-embeds-Python case feels less ready, only because #1308 (#1056) means that users have to be somewhat careful with awkward memory management. With that issue complete, I could feel confident in releasing a 1.0 for production readiness.

If stability is also a criterion, there's a few more things that I would still like to iterate upon before I think we're at a place where breaking changes are less likely to be necessary. For example, features like #991 and #1068 may require a rewrite of the current PyCell system (at least internally, and possibly with some external-facing effects). We should decide if we're ok with considering a 2.0 release (and beyond) not that long after 1.0 if we have breaking changes we want to move forward with. The answer to that would dictate how far off 1.0 is in my opinion.

[davidhewitt]

... and additionally, if we have both 1.0 and 2.0 releases, what level of support / backporting would we offer to 1.0? (etc.)

[mejrs]

Well, there are several things that are in the works, so it would be a shame to not have them in the stable 1.0. The ones I immediately think of are:

What springs to mind for me is:

• Do we want to rework traits at some point?
• Do we want to support multiple interpreters? That also can be a breaking change depending on how things are done.

We are not a standalone crate, so that makes a stable API harder. How would this work w/r to Python releases? It releases a new 3.x version roughly every year. Does that mean we have to make a new major version every time that happens?

[davidhewitt]

That's a really good point - and yes, I think we would have to release a breaking major version every year.

[birkenfeld]

Why? Can't support for a new version be added while keeping API compatibility?

[davidhewitt]

I was thinking more about dropping support for end-of-life Pythons and MSRV bumps - which I guess we don't have to do, but it would be nice to be not constrained backwards from making progress.

[aviramha]

It's seems that we all agree that there needs to be some visible and solid targets for 1.x. How about using GitHub projects' feature? Create a board for 1.x release?

[aviramha]

@davidhewitt I don't mind taking charge of the release/project management if needs help.

[davidhewitt]

Sure thing @aviramha - I've sent you an invitation which should give you access so that you can create and manage a 1.0 release board!