Should Neon use an application version number to manage client-side updates and migrations?
When a user opens a newer version of Neon, the application could compare the current Neon version with the version previously used by that client. If the versions differ, Neon could run any required update tasks once and then store the new version number.
Issue #1394 is one example of where this could help. Built-in sample files are currently compared every time the Dashboard loads. With version-based update handling, this synchronization could instead run when the Neon version changes.
A general version-based mechanism could also support other future updates, rather than implementing repeated checks separately for each feature. Diva’s version-handling approach may be a useful reference.
Should Neon use an application version number to manage client-side updates and migrations?
When a user opens a newer version of Neon, the application could compare the current Neon version with the version previously used by that client. If the versions differ, Neon could run any required update tasks once and then store the new version number.
Issue #1394 is one example of where this could help. Built-in sample files are currently compared every time the Dashboard loads. With version-based update handling, this synchronization could instead run when the Neon version changes.
A general version-based mechanism could also support other future updates, rather than implementing repeated checks separately for each feature. Diva’s version-handling approach may be a useful reference.