Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make Core Data migration test dynamic and future-proof #18797

Open
mokagio opened this issue May 31, 2022 · 3 comments
Open

Make Core Data migration test dynamic and future-proof #18797

mokagio opened this issue May 31, 2022 · 3 comments
Assignees
Labels
Testing Unit and UI Tests and Tooling [Type] Task

Comments

@mokagio
Copy link
Contributor

mokagio commented May 31, 2022

See discussion in this PR

@mokagio mokagio added [Type] Core Testing Unit and UI Tests and Tooling labels May 31, 2022
@mokagio mokagio self-assigned this May 31, 2022
@mokagio mokagio changed the title Make Core Data migration test dynamic and futre-proof Make Core Data migration test dynamic and future-proof May 31, 2022
@mokagio
Copy link
Contributor Author

mokagio commented Nov 20, 2024

@jkmassel @kean @crazytonyli @dcalhoun how do you feel about this?

If you think it's still worth keeping it the backlog, I'll shadow it in our Apple Core board in the Automattic org to avoid forgetting about this. Otherwise, we can close and move on.

@kean
Copy link
Contributor

kean commented Nov 20, 2024

We should be able to safely remove the first 120+ models. They have a significant impact on the app size.

Screenshot 2024-11-20 at 9 13 28 AM

In the worst case scenario, someone will need to re-install the app.

@mokagio
Copy link
Contributor Author

mokagio commented Nov 25, 2024

We should be able to safely remove the first 120+ models. They have a significant impact on the app size.

@kean sounds good to me, if you have the bandwidth, do you mind addressing this?

Based on that, maybe we can change the expectation on the migration tests to focus on expiration data rather than coverage? I.e. Does it really make sense to support migrating through years worth of versions? It might be a better tradeoff to accept a technical lack of migration support when in practice most users would be on relative recent versions, for which we'd have dedicated and easier to maintain tests?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Testing Unit and UI Tests and Tooling [Type] Task
Projects
None yet
Development

No branches or pull requests

2 participants