'v' prefix on source based modules

[TypeMayVary]

I'm managing a fair amount of projects that make use of a single mono-repo of terraform modules. We're looking into how to make some blanket changes to all module usages and keep that at the latest versions. tfupdate seems perfect for this, but we don't prefix tags with 'v' hence tfupdate doesn't correctly pick up these source attributes to modify with the --version value.

I'm just wondering, was there any specific logic behind why the ?ref=v couldn't just be ?ref= instead? I didn't want to go winging in a pull request or anything for this small change if there may have been a good reason for this setting.

[minamijoyo]

Hi @TypeMayVary, Good point!

Implicitly assuming the 'v' prefix is just a convention. As you pointed out, we can specify any Git ref in the Terraform specification. Furthermore, this is not limited to git; there are many variations of the source attribute of Terraform module blocks, and tfupdate does not currently cover all specifications.
https://developer.hashicorp.com/terraform/language/modules/sources#selecting-a-revision

Historically, I first implemented the provider's version attribute update, then the registry module's version attribute update, and then the Git module source's ref format, so it was natural to use the version number as an argument.

While it is easy to make the 'v' prefix optional using regular expressions v?, I'm concerned about the ambiguity that remains when considering Git branch names or tags. Having said that, it seems feasible to make v optional only in cases where it appears to be a version number, and to retain v if it is present before the update. This may be the minimum change required to meet your use case.

As a more comprehensive solution, adding an exclusive ref argument alongside the version argument for the module subcommand might eliminate ambiguity.

If you are willing to implement it, either design is acceptable as long as it maintains backward compatibility.

[TypeMayVary]

Thanks for taking the time for the in-depth response.

I'd lean more towards adding a ref argument based on your points above, your point around ambiguity in particular made me think of Murphy's Law. Also as I am relatively fresh to Golang I think it'd be a better task for me to help my own learning, as well as better for the project itself. I'll look to work it in in the coming weeks