I understand that workaround for baselines. I would object to it being acceptable however.
It diminishes the usability of a test case management system to have to manually manage test IDs. To do this, we’d need to 1) manually manage the ID creation to avoid clashes, or 2) build something custom to generate unique IDs or 3) use something generally human-unfriendly like a UUID.
Even if those were acceptable workarounds, it also introduces an problem in that if we have a duplicate test case for every release, we’ll eventually end up with tens of thousands of cases. So, let’s say I have a failed test and need to look it up. If I search by UUID, I might get 10 matching results (one for each release) with no way to tell which version I need to look at. I have to manually click into each one to find the right release This happens now and we are only tracking 3 releases in Testrail. See screenshot below. Which test case is which? It’s not a scalable solution.
I would suggest that versioning of a test case across releases is critical feature for a test case management tool. The baseline feature was nice try, but honestly it seems like a workaround to meet a marketing/sales need rather than something that a software team could use with thousands of test cases and an automated test runner.
As a customer who truly enjoys Testrail and uses it nearly every day, I would ask that you refactor how you handle test case versions and look to source control system for design patterns. For example, I should be able to just switch to a version of a suite/projects and see/search all the cases as it existed at that time without having to click and open each one to see the version.