Dropping root package.json version

[overbit]

TL;DR;

The proposal is to remove the version from the root package.json and the process in place to bump it on release, and update the amplication-client to rely at build-time or run-time exclusively on the github release version as per amplication website.

Details

Currently we rely on the package.json version to understand what version of amplication we are running.
This value, is used during the client build process to save the version that will be shown in the client interface.

As amplication nature is not monolithic but services based, this unique version is not ideal.
Moreover, the process of updating package.json version, makes the version of Nx, currently used in amplication, flagging all the projects in the monorepo as affected by a change, and as a consequence, our deployment strategy will process all projects as changed even if we only touched, i.e. amplication-server.

[yuval-hazaz]

@overbit I think we should split the discussion to two parts:

1. How we want to manage the versions on Amplication with nx, versioning strategy, reason to change the current state, etc
2. Once we agree on that, we can look into how to achieve that, what to do with the client, and what to do with the package.json

[overbit]

so, in other words, option 3 says - Keep using nx as usual for everything, but stop using it for version numbering.
Instead of counting on the version number from package.json we will use releases and tags on GitHub.
Because we do that, we will be missing the ability to show the version number in the UI - and to workaround it, we will be fetching the version from GitHub directly, assuming that the latest version on GitHub is always live on prod. if that is what you mean, I don't think it is a good solution for various reasons. Or do you suggest something else?

Nx was never the owner of versioning since it doesn't need or care about that package.json version to calculate the affected applications.

For the client we will collect it at build time so there is not runtime dependency on GitHub from this point of view.
Here is what I mean in code:
https://github.com/amplication/amplication/pull/6787/files#diff-9634303137442d185bc523324a75aef222e748c772138aacc82e00e1f8d3ba10R17

[mulygottlieb]

@yuval-hazaz what is bothering you regarding the last part about how to show the version number in the client? Would you like to suggest a different approach?
Remember that we do want (IMO) to show one unified version to the user in the UI, that corresponds with a GH release (and release notes), and GH published release seems right.
@overbit I don't understand how this can be not a runtime dependency - if we release a new version with no client changes, the client doesn't get rebuilt, so how will it get the new version number?

[overbit]

We will also be able to make version.ts part of the repository and use a manual workflow to update them and create a tag that will be used in production releases. I'll prepare an example with a diagram to showcase the idea.

[overbit]

Here the solution with a video showing the new flow:
#6787