Yes, you can absolutely use versioning with deployments in Prefect 3, and I can explain exactly how it works! When you deploy a flow with different versions: 1. Both versions will be preserved in the deployment history 2. The newest version (version=2 in your example) automatically becomes the "live" version 3. The previous version (version=1) remains available but becomes inactive This means that: - You can track changes over time - You can roll back to previous versions if needed - You can promote older versions to be the live version again The versioning system is quite flexible. When you deploy a flow, you can: - Explicitly set versions (like your example with version=1, version=2) - Let Prefect automatically handle versioning (it will increment automatically) - Use Git commit hashes as versions (if deploying from a Git repository) Here's a practical example of how you might work with versions:

python
# First deployment
flow.from_source(
    source="./flows",
    entrypoint="my_flow.py",
    version="1"
).deploy(name="my-deployment")

# Later, deploy an updated version
flow.from_source(
    source="./flows",
    entrypoint="my_flow.py",
    version="2"
).deploy(name="my-deployment")

You can find all the details about deployment versioning in the official documentation. One important note: Some deployment properties persist across all versions to avoid execution issues when rolling back or promoting versions. This ensures stability when managing different versions of your deployments. Would you like me to explain any specific aspect of deployment versioning in more detail? For example, I could elaborate on how to manage versions through the UI or CLI, or how to roll back to previous versions.

Based on my research, I need to correct my previous response. For self-hosted Prefect servers, the versioning behavior is actually more straightforward: When you deploy a flow with different versions: 1. The new version (version=2) will REPLACE the previous version (version=1) 2. Unlike Prefect Cloud, self-hosted servers don't maintain the full version history by default 3. Each deployment maintains only its current/active version This means that in your scenario:

python
# First deployment with version=1
flow.from_source(
    source="./flows",
    entrypoint="my_flow.py",
    version="1"
).deploy(name="my-deployment")

# Later, deploying version=2
flow.from_source(
    source="./flows",
    entrypoint="my_flow.py",
    version="2"
).deploy(name="my-deployment")

Version 2 will replace version 1 entirely. The version parameter essentially acts more like a tag or identifier rather than maintaining a full version history as you might find in Prefect Cloud. If you need to maintain multiple versions simultaneously in a self-hosted environment, you would need to: 1. Use different deployment names for each version 2. Manage the versions yourself through your deployment naming convention For example:

python
# Deploy version 1
flow.from_source(
    source="./flows",
    entrypoint="my_flow.py",
    version="1"
).deploy(name="my-deployment-v1")

# Deploy version 2 as a separate deployment
flow.from_source(
    source="./flows",
    entrypoint="my_flow.py",
    version="2"
).deploy(name="my-deployment-v2")

This is one of the key differences between self-hosted Prefect and Prefect Cloud - the Cloud offering provides more sophisticated version management features out of the box. Would you like me to explain more about how to effectively manage multiple versions of deployments in a self-hosted environment, or would you like to know about other differences between self-hosted and Cloud deployments?