add notes on architecture discussion
This commit is contained in:
parent
19b7ff6c5d
commit
84d9fac803
1 changed files with 13 additions and 0 deletions
13
meeting-notes/2025-02-26 version drift.md
Normal file
13
meeting-notes/2025-02-26 version drift.md
Normal file
|
@ -0,0 +1,13 @@
|
|||
Managing version drift
|
||||
|
||||
Attendees: Nicolas, Kiara, Valentin
|
||||
|
||||
Problem: if we want to allow users control over when to update, would this not mean we may not tightly couple our Django data model with the underlying versions of module options (the "type" equivalent, where actual configurations are "values")?
|
||||
|
||||
- decouple the types in the deployed Fediversity code from past versions using json-schema?
|
||||
- would we need to store the json-schema? yes
|
||||
- would we need to store a way to display each json schema even if already have a way to visualize forms from json schema? if we want to explain schema changes requiring user decisions (if not also just communicating option addition/removal) then yes
|
||||
- is diffing json good enough for presentation? likely not. have we not lost too much structure? yes. we'd need to be able annotate the difference between schemas, which are essentially another form of migrations, except not at the ORM schema level
|
||||
- most of the time we'll only need to diff subsequent versions, but if we're good we'll make those mappings transitive
|
||||
- what about users wanting to update applications at different times?
|
||||
- for now let's keep this out of scope
|
Loading…
Add table
Reference in a new issue