Document compatibility guarantees

[burmako]

As discussed in #1, one of the main reasons for introducing StableHLO is being able to provide compatibility guarantees for MHLO while keeping MHLO as flexible as possible. This is something that we can start doing right now, and within this ticket I'll work on putting together a proposal for what this means exactly.

[burmako]

Quick update on the progress with this ticket, because I know that some community members are eagerly awaiting compatibility guarantees from StableHLO:

• (M1) This week, I'm prioritizing turning StableHLO into a drop-in replacement for MHLO within the MLIR-HLO repository, which involves Implement Python bindings #9, Migrate from MLIR-HLO's CHLO to StableHLO's CHLO #10 and Create a bidirectional conversion between StableHLO and MHLO #11. Much of this work is happening in the MLIR-HLO repository, where pull requests and code reviews are internal to Google, but I'll be providing updates on the tickets linked above. Hoping to be done with this by EOW 8/28.
• (M2) That will unblock all sorts of experiments with StableHLO, including prototyping StableHLO usage in JAX, which I'm planning to look into next week.
• (M3) Also next week, I will start working on compatibility guarantees and, if time permits, will share something by EOW 9/4. The outcome of this work will be a pull request with a Markdown document that will propose a compatibility policy for StableHLO.
• (M4) Then, we'll be able to have a concrete discussion about the proposal. Once we have consensus, we'll merge the pull request and this document will become the source of truth for StableHLO.

[burmako]

The most challenging part of M1 (see above) is done. StableHLO now has Python bindings, has been integrated into the MLIR-HLO repository, and both CMake and Bazel builds are working over there.

This enabled JAX to start using StableHLO's Python bindings (jax-ml/jax@12cb55d). At the moment, JAX is only using the CHLO dialect from the StableHLO repository, and next week I'm planning to work with @hawkinsp to also add a StableHLO lowering. (This will need a conversion from StableHLO to MHLO which I hoped to land this week, but I'll need to travel this weekend, so landing got pushed back to early next week).

On a related note, @GleasonK has started working on #34 to explore the newly introduced binary serialization functionality in MLIR upstream, which will be crucial for our compatibility work. Kevin and I will be working on compatibility guarantees together, along the timeline discussed above (sharing a proposal by EOW 9/4 or a bit later, starting a community discussion around that).

[burmako]

Handing this off to @GleasonK who has made great progress with binary serialization for StableHLO and CHLO in #60 and #66. Now that we have a concrete implementation of this, we can talk about compatibility in more detail. Versioning work is still ongoing upstream, but there's already plenty to talk about even before it materializes in an RFC.

[GleasonK]

Spoke with @burmako. The purpose of this issue was surrounding creating a proposal, as stated in a previous comment:

The outcome of this work will be a pull request with a Markdown document that will propose a compatibility policy for StableHLO.

In that regard, this issue is complete as the markdown proposal exists in #115. Discussion of requirements and conversation around finalizing compatibility guarantees should take place on #115.

Closing this issue to avoid any duplication.