The parent feature has been tried before in some form, and one of the issues brought up was versioning.
As services version, properties are added to models, models are added, and parameters are added. Worse, they are sometimes removed or the type or required state changes. We need a way to version.
Mentioned was one team that had an all-encompassing model that tried to accommodate any other version of that model, and would filter or morph properties as needed. For Rust, we might instead consider TryFrom and/or From implementations between versions.
For traits, we could generate different versions of traits for each service version, perhaps making older versions supertraits of newer versions. If ever a version was deprecated, remove it from the list. Since these crates won't likely be public - and won't likely be libs anyway - semver is less of a concern.
The parent feature has been tried before in some form, and one of the issues brought up was versioning.
As services version, properties are added to models, models are added, and parameters are added. Worse, they are sometimes removed or the type or required state changes. We need a way to version.
Mentioned was one team that had an all-encompassing model that tried to accommodate any other version of that model, and would filter or morph properties as needed. For Rust, we might instead consider
TryFromand/orFromimplementations between versions.For traits, we could generate different versions of traits for each service version, perhaps making older versions supertraits of newer versions. If ever a version was deprecated, remove it from the list. Since these crates won't likely be public - and won't likely be libs anyway - semver is less of a concern.