Unclear demotion behavior about gto HOT 4 CLOSED

3. Disallow demote instruction and require to promote things instead.

I think this seems like the most straightforward approach. I don't think the convenience is worth it here where users probably want to be very explicit about what is currently active in each environment.

By the way, can a version that's active in any environment be unregistered? How does/should that work?

from gto.

By the way, can a version that's active in any environment be unregistered? How does/should that work?

Good question! Right now it works like this. If you unregister a version which is present in any environment, it gets demoted from them automatically. That means (among other) when you'll run gto show, you'll won't see this version promoted, or gto audit will show that it got demoted at the moment you unregistered the version.

As unregister is undoable, to promote model from the same commit once more, you'll have to register new version in the same commit (assuming that registration is a requirement for promotion, which is the default behavior).

from gto.

5. Another variation of option 2 could be removing demote command and asking to deprecate things:
   • e.g. gto deprecate rf v2 will deprecate v2 completely, so it gets automatically demoted from all envs.
   • gto deprecate rf v2 production will deprecate v2 from using in production env. So it gets automatically demoted from production env. That sounds clearer to me than using gto demote rf production - because in the latter you doesn't specify which version you're demoting (but we still can print demoted version in a cmd output FYI).

How git tags will look like in this option:
[email protected] - version registration
rf@!v1.0.1 - version deprecation (should you be able to undo this action any other way except for git tag removal?)
[email protected]!production - version deprecation for particular env (should you be able to undo this action any other way except for git tag removal?)

from gto.

Considering current implementations with labels in #219, I'm going to use the 5th approach above.
If you deregister a version, all labels of that version are also considered inactive.

from gto.