#8 File format versioning

Ouvert
Créé il y a 7 ans par caryoscelus · 4 commentaires

For compatibility reasons, it would be nice to have both general format version and node versions.

For compatibility reasons, it would be nice to have both general format version and node versions.
caryoscelus a commenté il y a 7 ans
Propriétaire

Node can be versioned inside tags. NodeName#version syntax can be used. For that reason, type specializations will be using '/' as separator instead. I.e. Average/Real#1.

Node versioning should be implemented along with new node system (#51).

Old version nodes should be convertible to new. It should be possible to disable compiling old node versions.

Possible implementations of old/new behaviour:

  • have old and new code inside one class (ugly)
  • have few differently versioned classes inside one file (compilation controlled by CMake+cpp)
  • add new files for new node versions (compilation controlled by CMake)

Latter option seems like the best one.

Node can be versioned inside tags. NodeName#version syntax can be used. For that reason, type specializations will be using '/' as separator instead. I.e. Average/Real#1. Node versioning should be implemented along with new node system (#51). Old version nodes should be convertible to new. It should be possible to disable compiling old node versions. Possible implementations of old/new behaviour: - have old and new code inside one class (ugly) - have few differently versioned classes inside one file (compilation controlled by CMake+cpp) - add new files for new node versions (compilation controlled by CMake) Latter option seems like the best one.
caryoscelus a commenté il y a 7 ans
Propriétaire

Perhaps there's no rush to implement it, until we actually have nodes with changed behaviour (the last one was ColorMix, but it's already done).

Perhaps there's no rush to implement it, until we actually have nodes with changed behaviour (the last one was ColorMix, but it's already done).
caryoscelus a commenté il y a 6 ans
Propriétaire

So, how it should work:

  • node name is split into 'name' and 'version' (using # as separator)
  • version is in form major.minor
  • minor version update is 100% backwards-compatible (even rounding thresholds changes should lead to version bump) and partially forwards-compatible when possible
  • major version update means no promise of backwards compatibility, though we'd still like to make migration as painless as possible

This means:

  • node should have multiple versions registered
  • on load, if node of current major version is found, it is used, possibly upgraded to minor and note about upgrade is wrote into log
  • if document's minor version is newer, it is kept and user is warned
  • if document uses newer major version, user is warned and asked whether they want to try loading anyway (optional)
  • if document uses older major version, user is warned and node is migrated

Code-wise:

  • plain string->constructor map is replaced with 2(3?)-level string->version->constructor
  • version checks are performed on load
  • some ui mechanism should exist to negotiate with user
So, how it should work: - node name is split into 'name' and 'version' (using `#` as separator) - version is in form major.minor - minor version update is 100% backwards-compatible (even rounding thresholds changes should lead to version bump) and partially forwards-compatible when possible - major version update means no promise of backwards compatibility, though we'd still like to make migration as painless as possible This means: - node should have multiple versions registered - on load, if node of current major version is found, it is used, possibly upgraded to minor and note about upgrade is wrote into log - if document's minor version is newer, it is kept and user is warned - if document uses newer major version, user is warned and asked whether they want to try loading anyway (optional) - if document uses older major version, user is warned and node is migrated Code-wise: - plain string->constructor map is replaced with 2(3?)-level string->version->constructor - version checks are performed on load - some ui mechanism should exist to negotiate with user
caryoscelus a commenté il y a 6 ans
Propriétaire

On nth thought, it might be better to define versions in separate "import" section and use normal names in the rest of file.

On nth thought, it might be better to define versions in separate "import" section and use normal names in the rest of file.
Connectez-vous pour rejoindre cette conversation.
Chargement…
Annuler
Enregistrer
Il n'existe pas encore de contenu.