How to handle versioning for multi-sided ( frontend and backend) project?

Question

Our solution has 3 environments(development,staging and production), and Currently,each environment has it's own versioning.

e.g. Development :

Frontend --> 1.0.8.8.

Backend --> 1.0.15.12

Staging :

Frontend --> 1.0.2.2

Backend --> 1.0.7.5

We show our frontend version in our staging environments for the QA team.

The issue here is, which version should the QA use for reporting bugs, should the QA report bugs based on the version of Frontend or Backend version? Is it possible to mix both versions in one version which translated to backend and frontend later?

What is the best Practice for handling versioning? and What is the best practice for the QA to report bugs with a version number?

Answer 1

The main idea of specifying a version of a product in defect description is making dev engineer possible to trace-back the app the is currently under test to the particular commit under version control system.

What you show in your question is likely a build versions (not a version in terms of version control system since they likely look either as a commit hash or a revision number). So once your application consists of several components which are built independently from different repositories, then it makes sense to specify build versions of all the components (if a tester is not sure about which component incorporates a defect - for example when they perform integration or e2e tests)

In my practice we usually tag versions as RC# where # is a sequential number of a build under testing if we test a single component system, or for example RC#-SERVER RC%-CLIENT where # and % are corresponding sequential numbers of release candidates for either client or server component for client-server application.

Thus a developer can trace back the entire code snapshot to investigate what caused the issue.