Fix: #662

[shiv4nk4r]

Description

Fixes #662

Type of change

• [ ] Chore (changes which are not directly related to any business logic)

What's Changed

• [ ] Added version.tsx file in frontend/app/src/components/ui folder. Version exposes an enum, type and the component itself, the enum is used to drive the theme, defaulted to dark theme, can be updated in future.
• [ ] Added .env file in fronted/app/src folder with content VITE_VERSION=v1.0.0
• [ ] Modified the frontend/components/molecules/nav-bar file to include the new version component

[vercel[bot]]

@shiv4nk4r is attempting to deploy a commit to the Hatchet Team on Vercel.

A member of the Team first needs to authorize it.

[abelanger5]

Hey @shiv4nk4r, thanks for the PR! I think it would be better if the version was being returned from the /api/v1/meta endpoint, which is already being used and can be accessed via the useApiMeta hook. While this can mean that the frontend gets out of sync with the API and engine, the reason for this issue is that we'd like to confirm the version of the API and engine (typically not the frontend).

Another option would be to still have the frontend version, and display a warning to the user if the frontend version is out of sync with the API version.

[shiv4nk4r]

@abelanger5 thanks for the feedback. I would implement the version from the API, now coming to the frontend part this would require the maintenance of the frontend version every time there is a new deployment in the backend.

[abelanger5]

now coming to the frontend part this would require the maintenance of the frontend version every time there is a new deployment in the backend

Yes I agree, this should be out-of-scope for now. At some point we may want to warn if there's too high of a version skew but we don't have a policy around this yet, so I think just the API version will suffice.

[steebchen]

I think from the UI perspective it would be better suited to go into the settings, as you only need to see the version in rare cases. For example, we can put it in /tenant-settings/overview.

[shiv4nk4r]

I think from the UI perspective it would be better suited to go into the settings, as you only need to see the version in rare cases. For example, we can put it in /tenant-settings/overview.

We would need to update our docs for this in order for the user to know that there is something as version inside.

[shiv4nk4r]

think it would be better if the version was being returned from the /api/v1/meta endpoint,

Can I get some documentation for this ?