This is especially important when Production has tag '1.0', Dev has progressed forward, and we want to open, in Dev, the specific version (which is tagged '1.0'). This could be the case when we need to hot fix something in Production, but want to test it first.

Now we have a problem in Production, and need to replicate the issue in Dev.

So I want to open tag (1.0) in Dev...how do I do that?

Even if I compare 1.1 and 1.0 in LifeTime, I don't know for sure which version is opened in Service Studio. The merge dialog box gives me a timestamp of the version on the left and the right. So now I need to match the timestamp to a version, to a tag.

The problem, in simple terms, is that I can't be confident which specific version of the module I'm opening when I'm looking at tags. If there was some clear connection between a tag and a version, then I can be confident.

Thank you very much for raising this idea! I'm anticipating a good discussion here. :)

Even though we could implement your idea, I'm not sure if we will be addressing your needs. That's why I would like to raise some questions in order to understand that.

What about the dependencies of that application which could have been changed meanwhile? Open that application version without importing the correct dependencies of that version will it addresses your request?

In which environment you expect to publish that change from Service Studio?

As in my example, if I want to open tag '1.0', it would be the same as downloading version 5 from Service Center and opening that. So it would have references to the old dependencies... not the latest dependencies.

I would most likely publish the change in Dev first if I'm trying to fix an issue that's occurring in Prod.

I would test the hot fix in Dev first, then push it through TST, UAT, PROD.

After the hotfix is in Prod, I would then merge my latest changes that I had before the hot fix with the hot fix changes in Dev.