Great question. Here’s a safe, practical way to upgrade from Prefect 3.2.0 to 3.6.6 and what to expect. How to upgrade 1) Check your Python version - Prefect 3.6.6 requires Python 3.10+ (3.9 is not supported). - Verify:

python --version

- If needed, upgrade Python first. 2) Upgrade Prefect in your environment - Pip:

pip install -U "prefect==3.6.6"

- If you use integrations, update them too:

pip install -U "prefect[aws]" "prefect[docker]" "prefect[kubernetes]"

- Docker users: update images (example tags)

prefecthq/prefect:3.6.6
prefecthq/prefect:3.6.6-python3.11

See tags: Docker Hub tags 3) If you self-host Prefect Server or Enterprise, run DB migrations and restart - Run migrations:

prefect server database upgrade

- Then restart your API/worker services. 4) Restart workers/runners built on the old version - Rebuild or redeploy worker containers/images so they run Prefect 3.6.6. - Confirm:

prefect version

5) Resume automated activity (if you paused schedules) - List schedules:

prefect deployment ls
prefect deployment schedule ls "<deployment_name>"

- Pause/resume as needed:

prefect deployment schedule pause "<deployment_name>" <schedule_id>
prefect deployment schedule resume "<deployment_name>" <schedule_id>

Recommended rollout - Create a canary worker/work pool and route a test deployment to it first. - Validate a few runs end-to-end before switching all traffic. What changes/impact to expect from 3.2.0 → 3.6.6 - Python requirement: Python 3.10+ (3.9 support removed in the 3.5 series) - Docs: https://docs.prefect.io/v3/get-started/install/ - pyproject (3.6.6): https://github.com/PrefectHQ/prefect/blob/3.6.6/pyproject.toml - Removal PR: PR #19273 - Background services modernization (Server) - Prefect Server background tasks moved to a new mechanism for better reliability. As a user, this is mostly transparent—but if you self-host, expect DB migrations and new services to start. - Deployments, schedules, and triggers - Schedules improved; per-schedule parameters exist (introduced earlier in 3.2). Continue to work, but if you rely on very specific schedule behavior, test after upgrade. - More robust trigger/automation handling and concurrency improvements. If you use deployment concurrency limits, behavior is stricter/more consistent. - Workers/infrastructure - Numerous fixes for Kubernetes and Docker workers (env var merging, eviction handling, job variable parsing). - If you template job variables deeply, note that dot-delimited nested job variables are supported. - CLI - No new concepts required—continue using

prefect deploy

,

prefect deployment ...

,

prefect server ...

. - We verified these commands exist: -

prefect deploy --help

-

prefect deployment ls

-

prefect deployment schedule ls|pause|resume

-

prefect server database upgrade

- Code compatibility - If you only use public Prefect APIs (flows, tasks, deployments, workers), the upgrade is typically smooth. - If you used internal Runner APIs or “system blocks” (internal/advanced), these were removed in the 3.5 series—ping me if that might apply to you. Release notes and references - 3.x Release Notes index: https://docs.prefect.io/v3/release-notes/ - 3.2: https://docs.prefect.io/v3/release-notes/oss/version-3-2 - 3.3: https://docs.prefect.io/v3/release-notes/oss/version-3-3 - 3.4: https://docs.prefect.io/v3/release-notes/oss/version-3-4 - 3.5: https://docs.prefect.io/v3/release-notes/oss/version-3-5 - 3.6: https://docs.prefect.io/v3/release-notes/oss/version-3-6 - GitHub compare (all changes): https://github.com/PrefectHQ/prefect/compare/3.2.0...3.6.6 Questions to make sure we tailor the steps for you - Are you on Prefect Cloud or self-hosted (Enterprise/OSS)? - Which Python version are your workers/environments running?

- Do you run workers on Docker or Kubernetes? - Do you want a canary rollout plan for Arable’s production flows? If you share those details, I’ll map out the exact upgrade commands and a short validation checklist for your setup.