Is adding range information to an OpenAPI a breaking change?

[savage-alex]

Strings, Ints and Numbers have range information describing their either max and min length or values and increments.

Would we consider adding these to be a potential breaking change?

Assumption is normally its adding detail but what if there was no limit previously and now you are enforcing one?

String example (query param)

- name: manufacturerName
          in: query
          description: Car manufacture or brand name.
          schema:
            type: string
            minLength: 0
            maxLength: 100
            default: ""
          example: "audi"

Number example (query param)

- name: orderValueGreaterThan
          description: A filter on the list to return only orders with a value greater than a provided value. Allows up to 2 decimal places.
          required: false
          in: query
          schema:
            type: number
            format: double
            multipleOf: 0.01
            minimum: 0
            maximum: 100000000
          example: 100.99

Integer example (query param)

- name: offset
          in: query
          description: |
            The offset number from where the items should be listed. 
            Not including an offset will default to the first items in the list.
          required: false
          schema:
            type: integer
            minimum: 0
            maximum: 100000000
            default: 0
          example: 10

[acunniffe]

Hey @savage-alex -- I'm not sure we consider making the OpenAPI more 'strict' about this counts as breaking, especially if the underlying API behavior has not changed.

I think it can be argued that most OpenAPI specs and JSON Schemas are underspecified, that is they could be more 'strict' but are not. Required/optional is a good example. Most API properties appear in combinations, but since specifying a oneOf that describes each possible combination is not very DRY, we say required/optional, and accept that it's not quite right. Not every property can be optional, and if some are required others will be there too....

I worry adding rules like this will disincentive developers from making their specs more specific.

I think what we should do is add breaking change rules about changing these values, and separately (for teams that care about this), add a rule that requires properties to use these keywords and be very specific about the values they accept.

does that make sense?