#8 File format versioning

Aperto
aperto 7 anni fa da caryoscelus · 4 commenti

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 commented 7 anni fa
Proprietario

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 commented 7 anni fa
Proprietario

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 commented 6 anni fa
Proprietario

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 commented 6 anni fa
Proprietario

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.
Sign in to join this conversation.
Caricamento...
Annulla
Salva
Non ci sono ancora contenuti.