-
Notifications
You must be signed in to change notification settings - Fork 13
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
Improve version handling #12
Comments
w1th0utnam3
added a commit
to w1th0utnam3/fenris
that referenced
this issue
Nov 3, 2021
Workaround for vtkio issue elrnv/vtkio#12
elrnv
added a commit
that referenced
this issue
Feb 17, 2023
This commit switches model::Version to be an enum with legacy and xml variants to indicate which type of file the data came from and what version it was. This does not preclude the model::Vtk struct from being serialized either as legacy or xml formats. That functionality remains flexible. Fixes #12
elrnv
added a commit
that referenced
this issue
Feb 17, 2023
This commit switches model::Version to be an enum with legacy and xml variants to indicate which type of file the data came from and what version it was. This does not preclude the model::Vtk struct from being serialized either as legacy or xml formats. That functionality remains flexible. Fixes #12
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently the version in the
Vtk
type represents the version for both XML and Legacy formats, which have independent versioning.The problem is that a legacy file loaded as
Vtk
will be written with an incorrect version in XML and vice versa, unless the user explicitly updates the version. This is bad for usability because it puts the burden of learning aboutvtk
versions on the user and forces people to have to handle these cases explicitly.In the majority of cases, versioning should be handled automatically, and overridden if needed.
The current proposal to resolve this is to refactor version to be an enum as follows:
The rules for writing should be such be that the minimum compatible version is used for both Legacy and XML format. The implementer should consult the VTK docs for this. The automatic behaviour should be clearly documented in the code and updated whenever a newer VTK feature is added.
The text was updated successfully, but these errors were encountered: