Hi all, I am new to MLIR, and I have some questions about the MLIR version release cycle. It seems like most of the downstream project vendored the whole llvm project and manually update the git binding. This leads to a problem that there will be multiple versions of vendored MLIR in different downstream project and make collaboration between these projects more challenging (Like iree/torch-mlir). So is there any recommendation on when to update the MLIR binding? Does MLIR have an individual release lifecycle for downstream projects to follow?
There is no particular release cycle for MLIR, while we may start paying a bit more attention to the LLVM releases (for example by cherry-pick bug fixes or writing some release notes) to accommodate some distributions and packaging that relies on this, every downstream project has its own policy.
In general MLIR is still evolving fairly quickly, and staying close to the main branch is best practice. If you’re planning to interact with a specific project, you like should just get MLIR transitively through this project.
Thanks for your answer! I hope one day we can have SemVer and detailed changelog for more compatibility control. Binding to a git commit is not ideal for long-term development.
Technically we have SemVer with the LLVM releases I believe? It’s just that most downstream projects chose to stay closer to the main branch for their development. Downstream projects could have their own release using upstream releases as well, but ultimately it’s quite impractical for any downstream project to develop against multiple upstream releases and be able to mix-and-match: I don’t foresee this ever happening (LLVM itself which is much simpler already requires heroics to do that).
There is an attempt to bring some organization to the chaos here: https://github.com/llvm/torch-mlir/issues/1178
Steve
There was a long discussion about this topic:
Thanks! It seems like this approach can also benefit from GitHub CI.
Thank you! I will take a look on it.