Bump serialization version to 18.0.0#8080
Conversation
As a matter of policy, we should probably bump the version of the serialization format for every version of Halide -- even if changes are minimal-to-nonexistent -- to reinforce the fact that this isn't intended in any way as a long-term archival format. This PR suggests that we bump the major version to match the main Halide version, but I'm open for other suggestions.
I agree with this. The one aspect I'm not quite sure about is bumping serialization format versions when we make changes between Halide versions. One possibility is to mirror LLVM and have the .0 version be unstable, with all releases having .1 in their versioning. |
Meh -- I can live with this, though it rubs me the wrong way on principle, it's probably easier to follow suit. I'll update this accordingly. |
Agree. I don't love this approach from LLVM. Otherwise, though, we need some way of versioning in between to make sure that serialization is valid between Halide releases. |
shoaibkamil
left a comment
shoaibkamil
left a comment
There was a problem hiding this comment.
Would like to see what others think, but this approach LGTM.
steven-johnson
added
the
release_notes
* Bump serialization version to 18.0.0 As a matter of policy, we should probably bump the version of the serialization format for every version of Halide -- even if changes are minimal-to-nonexistent -- to reinforce the fact that this isn't intended in any way as a long-term archival format. This PR suggests that we bump the major version to match the main Halide version, but I'm open for other suggestions. * Update halide_ir.fbs
2 participants
As a matter of policy, we should probably bump the version of the serialization format for every version of Halide -- even if changes are minimal-to-nonexistent -- to reinforce the fact that this isn't intended in any way as a long-term archival format.
This PR suggests that we bump the major version to match the main Halide version, but I'm open for other suggestions.