Explore removing the use of a version_group_id

[joshmeek]

Current behavior

Currently when creating a flow you can provide a version_group_id that is used to version the flow (defaults to a slugified flow name and project name). Seeing as a version group isn't necessarily a thing this deserves some better naming / documentation.

Proposed behavior

Rename version_group_id to something like flow_group_name however we should still maintain version_group_id at the API level for backwards compatibility but remove references to it in the documentation.

cc @cicdw @znicholasbrown from discussion

[znicholasbrown]

Another idea to simplify the flow group/version group concept is to make flow groups scoped to projects and prevent a flow group from containing flows across projects. This would solidify this hierarchy:

tenant  ∟ project      ∟ flow group           ∟ flow                 ∟ task

[cicdw]

Building off of what @znicholasbrown said, there are a few "features" that version_group_id allows for:

• ability to change the name of a flow while maintaining its version history
• ability to change the project of a flow while maintaining its version history

I think that we could still support these two features while scoping Flow Groups to Projects; in fact, flows can already be moved between projects, so as long as we allow for updating the name we could maintain feature parity while simplifying the concepts.

[zanieb]

I'd be willing to look into this, seems like there will be lots of room for review.

[cicdw]

There are a lot of open design questions about what this could look like, how much to enforce at the DB level vs. the application level, and how to ensure this doesn't break any current user flows so I wouldn't spend too much time on this solo.