Openapi-specification: Open TSC Meeting, Thursday April 23rd 2020

[MikeRalphson]

NOTE: This meeting is on Thursday at 9am - 10am PT
Zoom Meeting link: https://zoom.us/j/975841675

In order to give some more visibility into the topics we cover in the TSC meetings here is the planned agenda for the next meeting. Hopefully this will allow people to plan to attend meetings for topics that they have an interest in. And for folks who cannot attend they can comment on this issue prior to the meeting. Feel free to suggest other potential agenda topics.

*Please submit comments below for topics or proposals that you wish to present in the TSC meeting

| Topic | Owner | Decision/NextStep |
|-------|---------|---------|
| Motion to remove OpenAPI.next branch. Local and GitHub backups exist | @MikeRalphson | @webron to clean up stale branches |
| 3.1, fake 3.1 or 4.0 |||

/cc @OAI/tsc Please suggest items for inclusion

[darrelmiller]

• 3.1 respecting semantic versioning - Explicitly call out that OAS has certain different behavior than JSON Schema.

[darrelmiller]

• 3.1 (ignore this edge case) - Align with JSON Schema

[darrelmiller]

• 3.1 Pre-process the JSON schema based on context

[darrelmiller]

• 3.5 Pseudo not breaking

[darrelmiller]

• 4.0 Align with JSON Schema (including dropping semver)

[earth2marsh]

I struggle to see that we get a benefit from semver that outweighs the cost of semver. I'd consider dropping semver from 3.1 (I don't see that 4.0 is required to drop).

[MikeRalphson]

I can't see why we would bump to 4.0 and remove semver. 3.5, or OAS Vista, yes.

[handrews]

I think there are several choices involved here and it might be helpful to split them. Right now I feel like the people who want to let the Schema Object remain incompatible with JSON Schema are having one conversation, and the people who just want to figure out the best way to communicate the changes around JSON Schema are having a different one. So:

1. Does OAS want the next version to be fully compatible with JSON Schema, in the sense that schema objects can be passed directly to JSON Schema validators, and the validation result is consistent with what an OAS documentation or code generation tool would document or produce?

IF NO:

1. a) Which incompatibility with JSON Schema is desired?
   
   
   
   1. Treating Schema Objects as templates even though they look identical to JSON Schemas (e.g. preprocess to remove required and maybe adjust exclusive* based on where the object is attached)?
   
   
   2. Simply accepting and documenting the remaining incompatibilities, and requiring specialized implementations (not just vocabulary extensions, as that won't work) to handle OAS Schema Objects that use those incompatible features
   
   

IF YES:

1. b) How is the OAS incompatibility between the new version and 3.0.x expressed?
   
   
   
   1. Preserve SemVer: 4.0
      
      
      
      
      
      1. by restricting incompatibilities to the Schema Object
      
      
      
      2. by throwing open the floodgates to some degree or another
      
      
      
   
   
   2. Discard SemVer entirely: 3.1
   
   
   3. Split the difference between proper SemVer (which has psychological / cognitive load problems relative to the actual breakage) and abandoning all meaning of numbering, by declaring that skipping a few minor numbers means that there are _limited_ breaking changes that will probably not impact many people, and/or are trivial for migration (e.g. exclusive*): 3.5
   
   

If we can answer the first question, then we shrink the set of answers we're debating for the 2nd question.