hello community, hello prefect team, i was wondering if there are any best practices around versioning of prefect deployments and using prefect with human users as well as machine users. we are aiming at running flows programmatically via the api by another service, as well as by human users via the UI. this requires a setup where each code revision has its own deployment to ensure stability of the interface for machine users. with the existing version property of a deployment, we would only have one deployment that would reference the latest version. the most forward way imo would be to make the version part of the deployment name and deploy each flow version individually. however, i am worried that this would clutter the prefect UI as there would be a ton of deployments with very similar names after a while. with lacking capability to group deployments in the UI, this could heavily harm UX. Is there any other approach that could satisfy both requirements, a tidy UI as well as versioned deployments?

Hey @Justin Trautmann 👋 an approach I’ve seen in the past is to include the git branch in the deployment name and then have the git sha as a tag. This way you can still identify what commit a deployment reflects, but you get less deployment sprawl.

thank you emil for your input. we already have one deployment per feature branch (with the branch name in the deployment name) but would now need additionally multiple deployments for each version of the main branch. in the end, we want to decouple the development process of teams that develop flows and the team that develops the service that runs flows. meaning, a flow dev team should be able to release a new version of a flow with breaking changes in the interface at any time and communicate this to their human users. at the same time, the team that develops the service that runs the flows should not be forced to update their service immediately but should still be able to call the older version of the flow until they find the time to adapt their service to the new flow version. this team could then delete (possibly in a cleanup flow) all older versions, once they updated to the latest version, leaving us with probably less than a hand full of deployment per flow, which is acceptable but still not the best UX. is there any feature that would allow us to group the different versions of deployments so that it is easy for human users to find the most recent version or is it planned to support true versioning in the future?

Personally I haven’t heard of any plans to allow for deployments with multiple versions. The best available feature for this problem is tags. We’ll continue improving the experience of using tags in the UI. That being said, multi-version deployments would be a great feature request.