Limitation: two versions cannot refer the same commit

[aguschin]

@aguschin not allowing two versions referring to the same commit might be limiting. I see at least one scenario when that would be desirable, say we register some prerelease version then see everything is ok, and register the a release version to the same commit.

Originally posted by @Suor in https://github.com/iterative/studio/issues/4418#issuecomment-1306876623

[aguschin]

Good feedback, @Suor. This will complicate things though, so I'm not sure if this case is sufficient for GTO to support that. The problem is that if you have many events referring the same commit (like register, assign, deregister, register new version, assign again, etc), that may cause confusion.

Also it's one of basic assumptions in GTO, so lifting that can cause changes in the code. This shouldn't stop us from supporting it if we decide it's right, OFC.

[arabold]

I second the feedback above. Let me give some additional details I also posted in Discord: https://discord.com/channels/485586884165107732/903647230655881226/1164270028925972491

This conflicts with the branching and versioning strategy we're using for our project. All models are part of a monorepo and we increase the version of the repo whenever there is any change to any of the models. There are some dependencies (i.e. the Docker images used, Terraform configuration settings, etc.) that are not necessarily tracked as part of the model folder but outside of it. Some of them might be located in a different repo. Therefore we tag every time we do a release whether something changed or not. But that guarantees we have a consistent versioning scheme across the whole stack. In an extreme case this could even lead to the dev environment using a different version than the staging environment but they both are based on the very same commit hash of the repo.

The problem is that I cannot create a new version for the same commit hash with GTO. I don't see an option to force adding it either. I was wondering if I could simply create the tag manually without using the GTO CLI, but I haven't tried that as it seems like going against the explicit decision of GTO not to support this particular use case. I don't want to start spamming our repo with GTO specific tags if it turns out that it doesn't work anyway. However, for that reason we cannot use GTO or Iterative Studio as our model registry for the time being.

[dberenbaum]

I haven't looked at how it impacts the code. From a high-level perspective, your use case sort violates the assumption that git should be the source of truth for changes in your project. On the other hand, we may be restricting usage by being overly opinionated. Happy to discuss further here or on a call.

[arabold]

That's exactly the thing. It is and it must be. The only way to know which exact version of the application stack is deployed is by verifying either the commit hash or the version number. I generally prefer version numbers for readability (obviously).

Hence the need to tag my repo with a new version once we have updated any part of the application stack. Not all changes are possible to do purely in code though, i.e. sometimes you have a Terraform variable that changes for the environment that's not part of any actual code commit to the models repo. We need to be able to tag/version this change nonetheless as we redeploy and thus the deployed environment changes as well.

Hope that makes sense. Happy to discuss further.