...

• you can create a Test Set for this purpose and add a specific label to it (e.g., "regression"), and then you test for covered issues requirements of previous versions
• you can create a "regression Test Set" for each version by adding cloning the previous version regression test set tests and then new add more tests

Example: You're working on product v3.0 and want to do regression testing to make sure you have not broken anything. If the previous version, v2.0, had already some regression tests in a specific test set, then you can clone it and add all tests from that specific test set and all the ones some more tests for validating v3v2.0. 

Using the Test Repository

The Test Repository organization follows an hierarchical, tree-like way of organizing Tests within folders. Since a Test can only be part of one folder within the Test Repository, you have to think in an hierarchical way "What is most important? How do I look for the Tests to schedule executions?"

• create top-level folders for the things that are most important (e.g., "performance", "security", "smoke tests")
• create the hierarchy from the things that are most relevant and then decompose each one; for example, if your tests are the "components" of the system, you can create a top-level "components" folder and sub-folders for each sub-component
• avoid mixing execution- or planning-related aspects in the Test Repository or you'll get messed up
• don't organize the Tests based on things that are volatile or can rapidly change