search

SAP / abap-file-formats

File formats that define and specify the file representation for ABAP development objects
MIT License
58 stars 55 forks source link

Compatibility Contract #240

Closed schneidermic0 closed 2 years ago

schneidermic0 commented 3 years ago

A compatibility contract has to be specified. This means, how can we ensure that ...

schneidermic0 commented 3 years ago

Potential options might be:

  1. Allow to export in a specific version
  2. Support latest format in all releases
  3. Automatic conversion/migration of existing repository content
larshp commented 3 years ago

whats the ambition for "lower releases", regarding version, 702?

schneidermic0 commented 3 years ago

In the sense of cross transport/"downport" of functionality developed in a higher release and stored in a repo. It does not mean that lower releases have to support the same data model of an object type (i.e., if new object types introduce new fields, these don't need to be supported in lower releases).

But you are right, I didn't mention that this is most probably a SHOULD and not a MUST. I have added this information to the issue description.

larshp commented 2 years ago

My point of view for abapGit vision: can deserialize all version(also old abapGit XML), and serializes always to the latest version(assuming the user runs the latest abapGit and it implements the latest file format version)

For helping users, some standalone functionality(github app, github actions or similar) which can easily convert a repository to the latest version.

schneidermic0 commented 2 years ago

For the implementation that we want to use for gCTS we plan following compatibility contracts:

Implementations of ABAP file formats ...

  1. MUST be able to DESERIALIZE file formats in a backward-compatible way. I.e., implementations which supported a new version of a file format must be able to deserialize older versions they serialized in earlier versions.
  2. MUST be able to ignore non-mandatory and unknown fields so that they are forward-compatible without increasing the formatVersion. This enables them to DESERIALIZE file formats in a forward-compatible way if the 'formatVersion' has bot been changed. [This is related to #248] I.e. If a new non-mandatory field is introduced, files in the repository can still be imported in newer format versions. The formatVersion does not need to be increased.
  3. MUST indicate if they do not support a formatVersion

File Formats SHOULD stay as compatible as possible so that it is still possible to deserialize file contents by older releases. For this it would be also helpful if additions to a file format (i.e. new no-mandatory fields) would not be considered as incompatible change.

schneidermic0 commented 2 years ago

Since the compatibility contract will be handled in different ways by the implementations of ABAP file formats, I think, no documentation in this repository is required.

Therefore, I suggest to close this issue.