Whenever talking about versioning, different things may come to the surface that may be somehow related.

To what versioning are you referring to exactly? Requirements versioning, test versioning?

Are you talking about tracking changes on your artifacts or on having explicit versions each time you change an artifact?

Let's see first how JIRA handles changes and versions in general.

How JIRA handles versioning

As preliminary information, JIRA issues are assigned to a given version, by specifying the "Fix Version" field. 

Besides this, JIRA ensures that changes are tracked under the History section available in the respective issue screen, so you know who changed what and when.

So, if you have a requirement (e.g. a story) for version 1.0 and you wish to change it somehow in another posterior version (e.g. v2.0), normally you will have to create another requirement issue to specify the new behaviour.

However, if you are changing the specification during the development lifecycle of that requirement, you can simply update its description and use JIRA workflows to guarantee that is being handled properly.

If you make changes in some of the attributes of a issue, it gets tracked in the History changes; however, there is no increment in the version (not in any other field) of the requirement because it is used for another purpose: to tell for which version you're delivering it. 

How does Xray handle "versioning" of Test cases

Versioning of Tests work in the same way as versioning of other issue types in JIRA. Since Xray's Tests are JIRA issues, we follow the same approach so your users work in the same manner they already do.

Having in mind that Test issues are like reusable test case templates, should you assign Test issues to a given version? If so, what would be the purpose of it?

The test specification has a lifecycle; although your tests may live accross many versions of your project, they're made in the context of some version, most prabably for the version of the requirement they aim to validate. Thus, assigning them to a version serves the purpose of tracking the specification+implementation of the test case, the first time they have been used. This way you can also track it in the Release as one artifact that needs to be "done" (i.e. specified/reviewed/approved).

But you may want to know the "version" (let's call it revision to avoid misunderstandings) of the Test that you ran in some iteration. Xray does not track revisions of Tests as numbers, in order to avoid unnecessary complexity. However, Xray tracks changes and keeps a version of the Test specification within each Test Run. 

Xray addresses versioning in the JIRA way, which we think is more elegant, while at the same time ensuring data consistency:

• whenever you schedule a Test for execution in a Test Execution, Xray creates an instance of the Test that we call Test Run; that Test Run contains the "version"/revision of the Test specification at that moment;
• you can go to an already recorded Test Run and reset the specification to the last/actual specification on the Test issue... or you can even merge it; the later means that only changed steps will be updated and other step results are not changed. More info can be found in the page Execute Tests;  
• normaly you work with the last "version"/revison of the Test (as you do for a user story, etc); however, if you really want to manage different versions of Tests at same time (assuming that they're actualy different), you can create different Tests, one per version

By persisting the Test specification on the Test Runs,  Xray ensures data consistency. The "version" of the Test that was executed in a Test Run, is persisted in the Test Run itself. That means that if you change a Test specification today, that won't affect your already recorded runs for that Test (unless you want to).