Explore removing the use of a version_group_id about server HOT 4 CLOSED

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.

from server.

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

from server.

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.

from server.

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

from server.