This sort of workflow unfortunately isn’t really supported by Terraform’s model. The usual way to represent something like this is for the configuration itself (in version control) to act as the “memory”.
In other words, you make changes to infrastructure by making changes to the configuration via pull request, and if you don’t change anything then
terraform apply is a no-op, preserving everything from the previous run.
You can get a little closer to what you want by introducing some sort of external configuration source. If changing the configuration in order to deploy a new version isn’t desirable, you can add some indirection by making Terraform refer to some other system using a
data block, and then have your release process include making a change to that other system.
As a concrete example, if you are using AWS you could create an AWS SSM Parameter that represents the current version, and use
aws_ssm_parameter to retrieve it’s value to use elsewhere in your Terraform configuration. Then when you wish to select a new version, you can have your release process write a new value into that parameter and then begin a Terraform run to apply that change without modifying the configuration.