we have control over this input; validation is great to ensure consistency, but I'd argue we should avoid "auto fixing" incorrect inputs.

If we don't want the v, then we shouldn't put the v in the release name, instead of auto-stripping it.

this can create a weird situation when we start thinking about future breaking changes.

If we treat the whole of terratest as having one "version", then this is fine. If we want to version each module individually, then this can easily create situations wherepick-instance-type/v2 usesaws/v3 but the customer is usingaws/v2, and thus types will be incompatible.

In fact since replace directives only affect the main go.mod file (not things which import it), this may not even be doing what you think it is. Thego.work file does this for local development.

I feel strongly that this command needs to continue to work for existing users.

The accepted way to do breaking changes is to add a version suffix to the import path. You don't have to do this with a new directory, you can just change the module declaration ingo.mod:

module github.com/gruntwork-io/terratest/v1

And make sure you tag appropriately.

Go tooling will allow the non-suffix'dgo get command to continue to work, by pulling the latestv0.x.x tag. New users (or folks who want to upgrade) would run:

go get github.com/gruntwork-io/terratest/v1

And they'll get the latestv1.x.x version that's tagged.

This is where we need to decide if we're versioning each module individually (in which case we also need to bereally careful about never letting module A return non-interface types from module B), or version all of Terratest together (this is what I would advocate for).