Rework Import/Export versioning mechanism: define the forward and backward compatibility
In our current implementation of Import/Export, we could not make the Import from the previous version of the Export.
https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/import_export/version_checker.rb#L30
From the discussion in !17949 (closed), it seems that we try to avoid/delay updating the version of import/export as much as possible because we don't want to break compatibility.
To continue reworking import/export, we will need to bump the version and still support (import) older exports.
The current implementation will block us.
There is a detailed proposal from Kamil how it could be changed: !17949 (comment 229383502)
Example 1:
Relations rename. We should be comfortable supporting both old and new relation schemes for a number of recent versions. We should avoid duplicating both relations in the export (currently, it hits performance/memory).
Example 2:
Having new relations added to Export/Import, it should still be possible to import older versions of the exports.
For these cases, having a separate version of the importer and the exporter could give us more flexibility.
For example, Importer v2.3
may not support exports made with Exporter v3.0
, but is aware of exports made with Exporter v2.1
and Exporter v2.2
and supports them. At the same time, compatibility with exports created by Exporter v.1.N
could be deprecated.
Concerns:
- To migrate to the new mechanism, we will need to have some transitional version of the logic, which is compatible with the current implementation.
- (please comment on the issue)