Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bump serialization version to 18.0.0 #8080

Merged
merged 2 commits into from
Feb 9, 2024
Merged

Bump serialization version to 18.0.0 #8080

merged 2 commits into from
Feb 9, 2024

Conversation

steven-johnson
Copy link
Contributor

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.

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.
@shoaibkamil
Copy link
Contributor

As a matter of policy, we should probably bump the version of the serialization format for every version of Halide

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.

@steven-johnson
Copy link
Contributor Author

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.

@shoaibkamil
Copy link
Contributor

Meh -- I can live with this, though it rubs me the wrong way on principle, it's probably easier to follow suit

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.

Copy link
Contributor

@shoaibkamil shoaibkamil left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would like to see what others think, but this approach LGTM.

@steven-johnson steven-johnson merged commit de8e39d into main Feb 9, 2024
14 of 16 checks passed
@steven-johnson steven-johnson deleted the srj/ser-ver branch February 9, 2024 16:55
@steven-johnson steven-johnson added the release_notes For changes that may warrant a note in README for official releases. label Feb 9, 2024
ardier pushed a commit to ardier/Halide-mutation that referenced this pull request Mar 3, 2024
* 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release_notes For changes that may warrant a note in README for official releases.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants