#8 File format versioning

Öppen
öppnade 7 år sedan av caryoscelus · 4 kommentarer
caryoscelus kommenterad 7 år sedan

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 kommenterad 7 år sedan
Ägare

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 refererade till detta ärende från en incheckning 7 år sedan
caryoscelus kommenterad 7 år sedan
Ägare

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 kommenterad 6 år sedan
Ägare

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 kommenterad 6 år sedan
Ägare

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.
Logga in för att delta i denna konversation.
Laddar...
Avbryt
Spara
Det finns inget innehåll än.