data migration notes #29

Merged
kiara merged 5 commits from data-model into main 2025-05-31 18:48:26 +02:00
Owner

closes Fediversity/Fediversity#105.

once accepted, i may:

  1. in Fediversity/Fediversity#100 update the assumptions
  2. in Fediversity/Fediversity#103 add these requirements and reference above assumptions
  3. add the tests at Fediversity/Fediversity#100 and/or Fediversity/Fediversity#341
  4. [~] mention requirements and data model at the proposal rewrite
closes https://git.fediversity.eu/Fediversity/Fediversity/issues/105. once accepted, i may: 1. [x] in https://git.fediversity.eu/Fediversity/Fediversity/issues/100 update the assumptions 1. [x] in https://git.fediversity.eu/Fediversity/Fediversity/issues/103 add these requirements and reference above assumptions 1. [x] add the tests at https://git.fediversity.eu/Fediversity/Fediversity/issues/100 and/or https://git.fediversity.eu/Fediversity/Fediversity/issues/341 1. [~] mention requirements and data model at the [proposal rewrite](https://git.fediversity.eu/kiara/fedi-goals/pulls/1)
kiara added 3 commits 2025-04-08 17:04:57 +02:00
fricklerhandwerk reviewed 2025-04-14 08:46:43 +02:00
@ -5,0 +7,4 @@
Assumptions:
* Our deployment fully controls all versions, bypassing concerns on version mismatches.

I'm not sure what this means. The text you commented out describes the transfer between providers, and a different provider may simply have a different release of Fediversity deployed. While this may be a future-me sort of problem, depending on the release cadence and upgrade adoption delay by providers it may not be all that likely that two providers run the exact same release, and we need to at least to take that into account. The minimum that should happen initially is providing a UI for the case where two providers don't have the same version even if nothing can be done about it, and then keep at the back of our heads a user story for migrating and at the same time bumping the release, or something like that.

I'm not sure what this means. The text you commented out describes the transfer between providers, and a different provider may simply have a different release of Fediversity deployed. While this may be a future-me sort of problem, depending on the release cadence and upgrade adoption delay by providers it may not be all that likely that two providers run the exact same release, and we need to at least to take that into account. The minimum that should happen initially is providing a UI for the case where two providers don't have the same version even if nothing can be done about it, and then keep at the back of our heads a user story for migrating and at the same time bumping the release, or something like that.
Author
Owner
agree, c.f. https://git.fediversity.eu/Fediversity/Fediversity/issues/100
Author
Owner

source host control over migrated versions is to be handled by #304

source host control over migrated versions is to be handled by #304
kiara marked this conversation as resolved
kiara changed title from WIP: data migration notes to data migration notes 2025-05-27 18:47:59 +02:00
requested reviews from fricklerhandwerk, Niols 2025-05-27 18:48:26 +02:00
kiara force-pushed data-model from 7a74e6454b to 5b40131319 2025-05-27 18:59:59 +02:00 Compare
kiara added 1 commit 2025-05-27 19:07:56 +02:00
kiara merged commit bc59794685 into main 2025-05-31 18:48:26 +02:00
kiara deleted branch data-model 2025-05-31 18:48:27 +02:00
Sign in to join this conversation.
No reviewers
No labels
WP2
WP3
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: Fediversity/meta#29
No description provided.