We have a very simple proposal here: we won’t break the bytecode format, preserving the ability to both deploy to and consume from version 0 (and any intermediate versions) moving forward, we’d like to document this on the website.
A year ago, we introduced a bytecode serialization format for MLIR. Since then we improved our serialization with a few features (like IR/dialect versioning), and a couple of months ago we discussed the case for MLIR Bytecode format stability and backward compatibility. Since then multiple community members and various companies (including Apple, Google, Modular, Nvidia) stepped up to help implement the remaining features we wanted before reaching a point where the bytecode format could be considered stable, and this is now complete.
In the process, we bumped the version of the bytecode 5 times, and we managed to preserve the ability to target any of the previous versions of the bytecode. We are now quite confident that we can preserve the stability of the format moving forward and we want to document this.
That said, it is important to realize that the promises of the bytecode format are made assuming immutable dialects: the format allows backward and forward compatibility, but only when nothing in a dialect changes (operations, types, attributes definitions), and this is the level of guarantees we’re introducing here.
No dialect in upstream MLIR is promising any guarantee at the moment, including the builtin dialect: if you are using tensor, memref, affine constructs, forward and/or backward compatibility may still break.
Dialect versioning is orthogonal to the versioning of the bytecode format itself: the feature introduced in IR/dialect versioning allows dialects to individually record their own versioning scheme in the bytecode and manage their evolution.
We will carefully consider versioning schemes for some dialects in-tree as they mature and requirements and needs are clarified. This is in particular important to get feedback from both active contributors and users/products.
In the meantime, if you have your own dialect that you need to provide guarantees, you may look into BytecodeDialectInterface to control your own dialect versioning (independent of the bytecode format) and implement backward compatibility schemes (back-deployment should also be possible, pending an extra API). Alternatively, the StableHLO project is using a different approach where the StableHLO dialect is cloned entirely to a new version to “freeze” it, and then the dialect conversion framework is used to manage forward and backward compatibility of the StableHLO dialect with respect to these “frozen” versions.
