Better define project import/export compatibility after enabling ndjson
Problem to solve
Currently, the Project import/export very vaguely describes the compatibility matrix: https://docs.gitlab.com/ee/user/project/settings/import_export.html.
It seems to define almost inifinite forward/backward compatibility of import/export
,
which is not true compared to practice on how we test it and how we use it.
We merged ndjson support for project import/export that vastly improves the process,
making it memory constant and allow to much easier import/export very big projects.
With the %13.0 we have great opportunity to use ndjson
by default and better define
the compatibility to reflect our practices.
Proposal
I propose to better define compatibility of Project Import/Export and define a removal of support for old format:
- we allow to import exported project only in GitLab newer or equal (export from %13.0 can be imported into %13.0, %13.1, and so on): as this is something that we test today as part of our testing suite
- we do not allow to import exported project if it was created be newer version (export from %13.4 cannot be imported into %13.0): we cannot test that, as we do not actively develop the older version of GitLab to adapt and support newer structure of data
- we define to drop the support for old format (non-ndjson) one in one of the future release, it could be %13.4
- our practice working with project import/export says that our Support team always when working with import/export functionality requests to use matching versions of GitLab to avoid problems with data migrations, schema mismatches, renames and new structures
Results
If we would better define that we could effectively close the #35861 (closed) and &2734.