You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In some situations, such as generating protocol shapes (not limited to, but in particular: traits), it would be beneficial to allow evolving models without breaking binary compatibility of generated code.
For example, adding a new field to a struct trait shouldn't break binary compatibility of the result.
We should come up with and agree on:
conditions under which we would generate a shape as bincompat-friendly
for example: all traits? per-namespace/per-shape configuration? Something like what we're doing for validated newtypes in Validated newtypes #1454?
an exact encoding that'll work across all supported Scala versions. Some starting points for discussion:
non-case classes
public getters
public withX (for a member named x) instead of copy methods
mutable builders?
and implement these for the next minor version (0.19), if possible.
The text was updated successfully, but these errors were encountered:
Related: #1485, smithy-lang/smithy#2243, Discord discussion
In some situations, such as generating protocol shapes (not limited to, but in particular: traits), it would be beneficial to allow evolving models without breaking binary compatibility of generated code.
For example, adding a new field to a struct trait shouldn't break binary compatibility of the result.
We should come up with and agree on:
withX
(for a member namedx
) instead of copy methodsand implement these for the next minor version (0.19), if possible.
The text was updated successfully, but these errors were encountered: