Skip to content

Conversation

@vbarua
Copy link
Member

@vbarua vbarua commented Mar 19, 2025

No description provided.

@vbarua
Copy link
Member Author

vbarua commented Mar 19, 2025

I noticed that we had 4 different definitions of the same enum, and thought it would be better to factor it out. I believe this is binary compatible, though I want to confirm that.

@yongchul
Copy link
Contributor

@vbarua it is binary compatible. Any reason to hold back this change? This is a good cleanup IMO.

@jcamachor
Copy link
Contributor

Thanks, @vbarua . Is there any remaining work or anything we can help with to get this PR merged? Any concerns about merging it? While this is a backwards-incompatible change, it'd be great to get this consolidation in place soon.

@yongchul
Copy link
Contributor

Oh... I didn't realize that the enum values actually don't match! :( As @jcamachor said, I still think this is a necessary breaking change to keep things in consistent state.

@vbarua
Copy link
Member Author

vbarua commented Apr 14, 2025

I'm focusing on substrait-io/substrait-go#128, which is actually somewhat related to my ability to check this.

didn't realize that the enum values actually don't match!

The other way to do this would to via slow migration, adding second field joint type field alongside the original ones (which we deprecate), have them co-exist for a number of versions, and then remove the old fields.

@jcamachor
Copy link
Contributor

Thanks, @vbarua . I think the gradual migration approach you're suggesting is less disruptive and should help unblock this PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants