This feature seems to have multiple requirements, so I am planning to split this into multiple tasks.

• Implement templates versions [template] to list down name, created at and created by for all the versions of the specified template.

Question: Should this list be sorted in reverse chronological order?

• Implement templates versions update [template] [version_name] to update the template to a previous version for debugging.

Question: Is my understanding for this feature correct? Would this impact other users using the template, or should I be able to update an existing workspace to use a previous version?

• Show workspaces using the different template versions via templates versions [template] --list-workspaces. We can also add a column that displays the number of workspaces using the template version by default (without the flag).

Question: In case the list is too long, would we rather implement templates versions show [version] that lists the workspaces using that version along with basic version details (name, created at, created by).

General question: Do any of these operations need to be access restricted?

@ammario @misskniss @tjcran It'll be helpful if we can answer these before starting work on this ticket.

@AbhineetJain thanks for looking into this.

Just to clarify, I think we should only show versions that have workspaces on them so the list is unlikely to become unwieldy for a while. Also, I think we can just delete template versions that don't have active workspaces when workspaces are deleted?

On CLI structuring:

• templates versions [template]
• templates versions update [template] [version_name]

It's typically an anti-pattern to have some default operation on the base command and then additional commands. The most obvious issue is that a workspace named update would be inaccessible, but it's also confusing just because it's not standard.

Some options:

• templates versions show <template> and templates versions update <template>
• templates <template> [--list-versions | --rollback <version> | --list-workspaces [version] | --delete]

... and there are other approaches.

Note that we use show instead of get around the CLI.

I think we should decompose this issue into the read operations and the update operations. I think there's a lot to consider in the design of the update operations. For example, there is confusion between template update and template versions update.

Another design to consider is coder templates pull --workspace <workspace> which would grab the tarball, and then you could create a new template with that tarball, and then create a workspace. This would involve just one small change to a command, but would make the UX more onerous.

Anyways, there's a lot of unknown with the update portion, so I think just focus on good read operations for now.