v1.4.22

Changes since v1.4.21:

REST:

• fix: Escape parameters named "service" appropriately
• fix: Support data models with their own ETag field
• chore: Prohibit required parameters of "interesting" types
• fix: Update the generator to use the new DiscoveryFormat methods
• fix: Generate additional properties for date/time-oriented parameters
• chore: Remove legacy features in REST generator configuration

GAPIC:

• feat: Validate resource name uniqueness to provide readable errors

v1.4.21

Changes since 1.4.20:

• REST: Place triple-backticks in Discovery-based generated code on separate lines
• GAPIC: fix: Generate appropriate XML documentation for resource name operators

v1.4.20

Changes since 1.4.19:

• fix: Work out which proto package we're generating with more nuance

v1.4.19

Changes since 1.4.18:

• Generate string and DateTimeOffset-based properties for "google-datetime" resource fields in REST generator

(This change was intended to be in 1.4.18.)

v1.4.18

Changes since 1.4.17:

• Updated protoc and gRPC plugin for GAPIC generator
• Regenerated protos in GAPIC generator
• Generate DateTimeOffset-based properties for "date-time" resource fields in REST
  • This was expected to include "google-datetime" as well, but a PR hadn't been merged

v1.4.17

Changes since 1.4.16:

• Dependencies updated, including in generated projects
• Snippets for streaming code dispose of the returned call (available as of GAX 4.4.0)

v1.4.16

Changes since 1.4.15:

• Fix issues with Bazel not building with latest .NET SDK when the home directory is read-only
• Revert to .NET SDK 6.0.408

v1.4.15

Changes since v1.4.14:

• Downgrade the .NET SDK just in Bazel to 6.0.402, which we investigate why 6.0.408 causes issues in Docker

v1.4.14

Changes since v1.4.13:

• Only generate files for mixins if that's all we're generating
• Pin generated snippets namespace to GoogleCSharpSnippets (which allows for reduced aliasing)
• Generate dependencies for known packages

v1.4.13

Changes since 1.4.12:

• Use new .NET-specific settings in the service config YAML file (e.g. for renaming APIs)