#8 File format versioning

Terbuka
dibuka 7 tahun lalu oleh caryoscelus · 4 komentar

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 komentar 7 tahun lalu
Pemilik

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 komentar 7 tahun lalu
Pemilik

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 komentar 6 tahun lalu
Pemilik

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 komentar 6 tahun lalu
Pemilik

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.
Masuk untuk bergabung dalam percakapan ini.
Memuat...
Batal
Simpan
Belum ada konten.