| * | 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!
|