2023-03-13 - Breaking Changes RFC

RFC: Breaking Changes

Discussion Notes:

• Let's review the RFC and get feedback on the scope and general direction
• If the group thinks the RFC has merit, and the scope is clear we have a quorum and could vote to move this forward today.
• Jeremy Huff walked us through the RFC... agreed to not read it line-by-line, but at a higher level (paraphrased/summarized)
• NOTE:  not intended to be comprehensive (not every kind of breaking change is covered in the RFC), but rather illustrative and to serve as guidance
• When will a version be decremented? 
  • It isn't clear.  Seems like it happened at least once in the past.
  • Shouldn't happen often, if ever.
  • It can't hurt to provide guidance on this regardless.
• Typo in data model section... "Change of a new optional field"
• What about required fields with default values? – Leave this up to the subgroup to sort out.
  • Do we need to spell out these permutations?
  • Add a bullet to the clarifications section?
  • Add something to the terminology section?
• What about changes to edge APIs?  
  • Not strictly controlled by OKAPI interfaces
  • Making breaking changes to edge APIs can really screw things up 
  • Marc Johnson not making breaking changes here is a policy decision, and really isn't unique to edge APIs.  Integrations exist which directly consume backend APIs
• What about changes to Kafka message formats/data models?
  • Should probably be addressed in the RFC in some way
  • At least make it clear whether this is in/out of scope for this RFC.
• What about changes to reference data?
  • Probably requires some thought.
  • Should be clear if this is in/out of scope for this RFC.
• Is renaming a module a breaking change?
  • This is certainly disruptive, especially on the DevOps/SysOps side of things
  • There could be some policy decisions here
  • Need to be clear if this is in/out of scope for this RFC?
• We ran out of time, but if there is any other feedback, please leave comments in the RFC!