typespec1-7  Exercise 1: A Compatible Member Service Change
===================================================================

members.tsp (TypeSpec 1.17.0, versioning 0.87.0; OpenAPI 3.1.0):

  import "@typespec/http";
  import "@typespec/versioning";

  using Http;
  using TypeSpec.Versioning;

  @versioned(Versions)
  @service(#{ title: "Member Service" })
  namespace Members;

  enum Versions { v1: "1.0", v2: "2.0" }

  model Member {
    id: string;
    name: string;
    @added(Versions.v2) nickname?: string;
  }

  @route("/members")
  interface MemberOps {
    @get list(): Member[];
    @route("{id}") @get read(@path id: string): Member;
    @added(Versions.v2) @route("{id}/nickname") @get nickname(@path id: string): string;
  }

oasdiff 1.33.0, changelog from openapi.1.0.yaml to openapi.2.0.yaml:

  info    response-optional-property-added GET /members              added the optional property `items/nickname` to the response with the `200` status
  info    response-optional-property-added GET /members/{id}         added the optional property `nickname` to the response with the `200` status
  info    endpoint-added                   GET /members/{id}/nickname endpoint added

IS IT SAFE, AND HOW I CHECKED
  Yes, by oasdiff's standard: 3 changes, all 'info', 0 errors. Checked two ways: the changelog above, and `oasdiff breaking ... --fail-on ERR`, which exited 0.
  Why it is safe: nickname is optional and appears only in responses (a client that does not know it ignores it); the new operation is an addition, so no existing call is affected.
  What this does not prove: that a real server keeps the promise, or that every client tolerates an unknown field (a client with a strict schema may not). oasdiff reads the two files and nothing else.

WHY THIS WORKS AS AN ANSWER
---------------------------
It is the 'nothing is wrong' case, which is worth having on record: the same procedure that finds errors in the next two exercises finds none here.