Discussion: Backwards compatibility policies

[kwannoel]

No backwards compatibility for:

• Experimental features
• Bugs (e.g. some Materialized View might work, but could be buggy in the long term due to some incorrect logic in an operator). User must re-create the MV.
  • The current approach for this would be to version the operator, and panic if we use an outdated version of it, telling the user to recreate the MV.
• Batch queries (between major versions)

Backwards compatibility for:

• Stream jobs (even between major versions).
• Batch queries (between minor versions).

[kwannoel]

For exprs e.g. CASE, ALL, is there anyway we can notify users of breaking changes? cc @wangrunji0408. Seems only release notes so far, but is hardly ideal. Perhaps if any MV contains an expression with a breaking change, we notify them on upgrade? 🤔

[wangrunji0408]

Good idea. We can record the RW version of each MV when it was created and check incompatibility issues on meta node, eventually notify users via pgwire. 🤔

[github-actions]

This issue has been open for 60 days with no activity. Could you please update the status? Feel free to continue discussion or close as not planned.