Skip to content
z4j docs

Changelog

Latest headline release: z4j v1.10.0.

Each package versions independently; the table below shows the current latest of every published package. The per-package history follows.

PackageLatestReleasedCategoryLicenseLinks
z4j1.10.02026-08-28UmbrellaAGPL-3.0-or-laterPyPI · GitHub · Docs
z4j-bare1.10.02026-08-28CoreApache-2.0PyPI · GitHub · Docs
z4j-core1.10.02026-08-28CoreApache-2.0PyPI · GitHub
z4j-scheduler1.10.02026-08-28CoreApache-2.0PyPI · GitHub · Docs
z4j-django1.10.02026-08-28FrameworksApache-2.0PyPI · GitHub · Docs · Upstream
z4j-fastapi1.10.02026-08-28FrameworksApache-2.0PyPI · GitHub · Docs · Upstream
z4j-flask1.10.02026-08-28FrameworksApache-2.0PyPI · GitHub · Docs · Upstream
z4j-arq1.10.02026-08-28EnginesApache-2.0PyPI · GitHub · Docs · Upstream
z4j-celery1.10.02026-08-28EnginesApache-2.0PyPI · GitHub · Docs · Upstream
z4j-dramatiq1.10.02026-08-28EnginesApache-2.0PyPI · GitHub · Docs · Upstream
z4j-huey1.10.02026-08-28EnginesApache-2.0PyPI · GitHub · Docs · Upstream
z4j-rq1.10.02026-08-28EnginesApache-2.0PyPI · GitHub · Docs · Upstream
z4j-taskiq1.10.02026-08-28EnginesApache-2.0PyPI · GitHub · Docs · Upstream
z4j-apscheduler1.10.02026-08-28SchedulersApache-2.0PyPI · GitHub · Docs · Upstream
z4j-arqcron1.10.02026-08-28SchedulersApache-2.0PyPI · GitHub · Docs · Upstream
z4j-celerybeat1.10.02026-08-28SchedulersApache-2.0PyPI · GitHub · Docs · Upstream
z4j-hueyperiodic1.10.02026-08-28SchedulersApache-2.0PyPI · GitHub · Docs · Upstream
z4j-rqscheduler1.10.02026-08-28SchedulersApache-2.0PyPI · GitHub · Docs · Upstream
z4j-taskiqscheduler1.10.02026-08-28SchedulersApache-2.0PyPI · GitHub · Docs · Upstream

History by package

Section titled “History by package”

z4j

v1.10.0 (2026-08-28)

  • added: Run strips on the schedules table, the schedule detail page and a new Schedules needing attention panel on the project overview show each schedule's last twenty fires as a picture, so a flapping schedule, one failing in bursts and one dead for a week no longer look alike.
  • added: A Health badge shows a schedule's run of consecutive failures against the circuit-breaker threshold while the schedule is still enabled; the brain counted this on every breaker tick and kept only the disable.
  • added: GET /schedules/runs returns the last N fires for many schedules in one request, as a per-schedule top-N read bounded by the retention cutoff.
  • changed: Wide tables scroll instead of losing columns, open on a chosen column set with a Columns chooser, never wrap header labels, and render dates on one line in dense views. Schedule rows are about half their previous height.
  • changed: The canvas tree separates queue wait from execution time on every node.
  • fixed: Both circuit-breaker reads of fire history are per-schedule top-N reads bounded by the retention cutoff on fired_at, so a caught-up or replayed fire stays visible to the breaker; they scanned every fire in the retention window on each tick.
  • fixed: The public demo showed every schedule as held, a blank fire-history card on every detail page, and sixty recent tasks instead of five. It now matches the API.

v1.9.1 (2026-08-27)

  • added: The container images are published, z4j audit export-head prints the authenticated chain head, schedule hold is visible and controllable from the dashboard, the worker configuration lint has a panel, and dead-letter requeue is reachable.
  • fixed: The scheduler no longer loses a fire to its own dispatch latency, and the published image carries current base-image security updates.

v1.9.0 (2026-08-25)

  • added: Pause and resume controls, authenticated deep health, worker configuration lint, scheduled audit-chain verification, and guarded restore from a previous-release backup.
  • changed: The database transition is a stop-migrate-start upgrade and is one-way. A database holding z4j-native schedules refuses the downgrade rather than dropping paused-schedule state, agent tombstones, or delivery-owner snapshots the older schema cannot reconstruct. Take a backup before upgrading; restoring it is the supported way back.
  • fixed: Startup now enforces a PostgreSQL connection floor, schedule cadence identity remains stable across runtime patches, and production environment settings fail closed.
  • changed: Published dependency floors now exclude vulnerable cryptography, protobuf, Sentry SDK, Django, and sqlparse releases.

v1.8.0 (2026-07-30)

  • added: Durable bulk retry. A bulk retry is now a request you can watch rather than a fire-and-forget button. The request identity, its audit row, and the complete per-task plan commit together, so the work that will run is decided up front. Submitting the same request again returns the original outcome instead of re-expanding the filter, which matters because the set of failed tasks keeps moving. Each task is claimed once at its send edge under a fleet-wide in-flight bound, and a running retry can be paused and later resumed.
  • added: Authenticated audit chain. The audit log is signed with a dedicated key held apart from the database, so audit history that verifies cannot be written without holding that key, and the head and row counts are authenticated rather than inferred from the rows themselves. Verification also accepts a head you exported earlier to storage the database role cannot write, which is what covers a log rolled back to an earlier authentic state; without that anchor the chain is evidence against everything that goes through z4j rather than against whoever holds the database. Existing history is classified and frozen as authenticated legacy history during the upgrade; where it cannot be classified beyond doubt the upgrade stops and asks for an explicit operator attestation rather than adopting history it cannot prove.
  • added: Issues moves into the dashboard as its own page, with ongoing and recovered filters served by brain-side filtering, and scheduler misfires now surface directly on the Schedules page.
  • added: Connection pool sizing is configurable. Pool size and overflow were fixed values, which made the brain's connection demand impossible to fit to a database server the operator does not control. Defaults are unchanged, so no existing deployment shifts on upgrade.
  • changed: Rolling upgrades are a supported configuration. The brain may run one minor version ahead of its agents, so the control plane and the fleet can be upgraded independently rather than in one window. Exercised in both directions against a real prior release.
  • fixed: Reliability hardening across delivery, agent buffering, and scheduling. Retry authority is bound to the worker generation that executes it, the agent buffer only ever adopts storage it can prove belongs to it, and the agent starts safely on filesystems that cannot lock reliably. Validated by a harness running real brain and agent processes against both supported databases.

v1.7.0 (2026-07-14)

  • added: Automation rule engine. Per-project rules watch a task or scheduler trigger and run a governed action (notify an operator, retry a task, or cancel a task), each with its own guardrails: a rolling-window circuit breaker that trips a runaway rule into notify-only, a per-project kill switch, and a dry-run mode that records what a rule would have done without touching anything. Destructive rules require admin authority; browser-session mutations require fresh MFA, bearer-authenticated callers follow API-key authority, and fire time rechecks the creator's current admin membership. Every firing lands on the audit log.
  • added: Issues (failure fingerprinting). Task failures group by a stable fingerprint so the same bug across runs and engines collapses to one issue with occurrence counts, an open vs recovered split, first and last seen, and the engines affected.
  • added: Scheduler reliability. Brain-side misfire detection flags any enabled interval or cron schedule whose expected fire is past a grace window (a dead or partitioned scheduler is the usual cause) and feeds it to automation, subscriptions, and metrics. Project-wide misfires are queryable from the REST API and a new CLI, and fire-now actions are attributed to the operator who triggered them. Fire history is range-partitioned for fast retention.
  • added: MFA trust shell. A TOTP second factor via any standard authenticator app, one-time recovery codes, and an opt-in remember-this-device cookie. Enforcement is opt-in and off by default; once a user is enrolled their session must pass the second factor before general access.
  • security: Hardening release. Closes a set of execution-path and step-up-authentication findings, plus a frontend and tooling dependency refresh. Operators are advised to upgrade.
  • changed: Verified data-safe in-place upgrade from 1.6.x on both PostgreSQL and SQLite (a populated upgrade preserved every row). The wire protocol is compatible for a rolling upgrade: upgrade the brain first, then roll the agents. Python 3.11 is the new minimum.

v1.6.9 (2026-06-23)

  • fixed: Reliability release. Eliminates a spurious shutdown-time error traceback on short-lived processes (one-shot management commands) by draining the agent runtime before the interpreter tears down its worker pool. Adds an opt-out for the liveness heartbeat on transient processes. Plus an audit-trail completeness improvement for the bulk-retry endpoint.

v1.6.8 (2026-06-08)

  • security: Follow-on security release. Closes two high-severity issues in the bulk-retry and mixed-version dispatcher paths that the Round 9 external audit surfaced on top of 1.6.7. Operators are advised to upgrade.

v1.6.7 (2026-06-07)

  • security: Security release. Addresses a high-severity issue in one engine adapter's retry surface plus supply-chain hardening across CI workflows. Operators running RQ or shared-Redis deployments are advised to upgrade.

v1.6.6 (2026-06-07)

  • security: Security release. Addresses a high-severity information-disclosure issue plus several lower-severity hardening items. Operators are advised to upgrade.

v1.6.5 (2026-05-27)

  • security: Security release closing multiple authentication, session, transport, and dependency-supply-chain hardening items. Operators are advised to upgrade.
  • changed: Password minimum length aligned at 12 characters across backend default, dashboard fallback, and operator docs.

v1.6.3 (2026-05-15)

  • security: Security release. Operators are advised to upgrade.

v1.6.2 (2026-05-14)

  • changed: Dashboard design system unified across every page: consistent headers, filter toolbars, search inputs, action buttons, empty states, and time-range pickers.
  • added: Search and state filters on the Agents, Queues, and Workers pages.
  • security: Frontend and tooling dependency refresh.

v1.6.1 (2026-05-13)

  • fixed: Dashboard bundle correction for the MFA enrollment and post-login challenge surfaces. In-place upgrade picks up the fix.

v1.6.0 (2026-05-13)

  • added: Multi-factor authentication. TOTP via any standard authenticator app (Authy, 1Password, Google Authenticator, etc.), single-use recovery codes, optional 30-day device trust. Opt-in: existing users stay unenrolled until they enable it.
  • added: Microsoft Teams notification channel. Workflows webhooks, Power Automate, and the legacy O365 connector all auto-detected at save time.
  • added: Sentry error capture, OpenTelemetry tracing, audit-log webhook forwarding, four Grafana dashboards, and a Live Activity Feed on the dashboard home.
  • changed: One bidirectional schema migration (upgrade and downgrade both safe on populated databases). No data migration required.

v1.5.1 (2026-05-12)

  • fixed: Brain memory hygiene under sustained burst load. Tunable via `Z4J_DATABASE_STATEMENT_CACHE_SIZE`.
  • added: Four new Prometheus gauges plus a Grafana dashboard so operators can verify operational health in their own environment.

v1.5.0 (2026-05-11)

  • security: Security release. Operators are advised to upgrade.
  • fixed: Task-correctness fixes around event acknowledgement, event-loop decoupling, and event deduplication.
  • fixed: Scheduler load-test fixes.

v1.4.0 (2026-05-03)

  • changed: The brain server, dashboard, REST API, audit log, and reconciliation all ship in a single `z4j` distribution. `pip install z4j` is the only install path operators need.
  • added: Engine adapters available via extras: `pip install z4j[django,celery]` for the full Django + Celery stack, plus extras for FastAPI, Flask, RQ, Dramatiq, Huey, arq, TaskIQ, APScheduler.
  • security: Security release. Operators are advised to upgrade.

z4j-bare

v1.10.0 (2026-08-28)

  • changed: Carried with the coordinated 1.10.0 fleet release. No behaviour changed.

v1.9.1 (2026-08-27)

  • changed: Carried with the coordinated 1.9.1 fleet release. No behaviour changed.

v1.9.0 (2026-08-25)

  • fixed: Unsupported agents back off instead of reconnecting forever, with stricter capability and lifecycle handling.

v1.8.0 (2026-07-30)

  • changed: Agent durability. Each process generation seals its own buffer before examining older ones, and only a buffer it can prove is exclusively held and belongs to this deployment is recovered automatically. Anything foreign or unreadable is left in place for a human rather than drained or deleted. On filesystems that cannot lock reliably the agent relocates to a private path and logs it instead of refusing to start.
  • changed: A close the agent cannot fix by reconnecting is now treated as terminal, so a rejected agent stops rather than reconnecting in a loop.

v1.7.0 (2026-07-14)

  • fixed: Agent runtime and dispatch fixes from a fleet readiness sweep, the Python floor raised to 3.11, and version unified with the rest of the fleet.

v1.6.9 (2026-06-23)

  • fixed: Shutdown lifecycle hardening: the agent runtime now registers its teardown to run before the process worker pool is shut down, drains in-flight work deterministically, and supports a heartbeat-less mode for short-lived processes. Removes the spurious shutdown-time error noise.

v1.6.8 (2026-06-08)

  • security: Dispatcher hardening: refuses retry against a legacy RQ adapter rather than falling back to a signature that would re-open a prior pickle-deserialization issue.
  • fixed: Brain-derived task name now wins over operator-supplied values in the Huey retry path.

z4j-core

v1.10.0 (2026-08-28)

  • changed: Carried with the coordinated 1.10.0 fleet release. No behaviour changed.

v1.9.1 (2026-08-27)

  • changed: Carried with the coordinated 1.9.1 fleet release. No behaviour changed.

v1.9.0 (2026-08-25)

  • changed: Coordinated 1.9 protocol and capability contracts, with stricter validation and fail-closed compatibility boundaries.

v1.8.0 (2026-07-30)

  • changed: Transport carries a versioned capability contract so the brain can tell what the connected agent is able to honour, rather than assuming. Redaction and path handling were tightened alongside it.

v1.7.0 (2026-07-14)

  • added: Failure fingerprinting support in the shared domain layer, so the same bug across runs and engines collapses to one issue.
  • changed: Python floor raised to 3.11 and version unified with the rest of the fleet.

v1.6.7 (2026-06-08)

  • changed: Python compatibility floor relaxed from 3.10/3.11 to 3.10 so adapters embedded in operator processes can install on the broader Python deployment base.

z4j-scheduler

v1.10.0 (2026-08-28)

  • changed: Carried with the coordinated 1.10.0 fleet release. No behaviour changed.

v1.9.1 (2026-08-27)

  • fixed: A slot the leader had already seen as due is no longer discarded because of the scheduler's own dispatch latency; the on-time judgement is frozen across retries for a bounded window.
  • added: Slots dropped by a catch_up policy are logged and counted; the on-time grace is configurable; an unexpected error in one tick no longer stops the scheduler.

v1.9.0 (2026-08-25)

  • added: Pause and resume controls, scheduler diagnostics, and cadence identities that remain stable across dependency and Python patch changes.
  • changed: The protobuf runtime floor is 6.33.5, above both the committed gencode minimum and the first advisory-fixed release.

v1.8.0 (2026-07-30)

  • changed: Schedule cursor authority. A schedule's next-fire cursor is normalised to a single cadence identity and advanced under the brain's authority, so a schedule cannot appear to be moving while never actually running. Databases that reached an affected pre-release state are repaired automatically and the repair is recorded in the schedule change log like any other transition.

v1.7.0 (2026-07-14)

  • added: Fire-variance metrics showing how far each fire lands from its scheduled time, and an info command that reports version, uptime, readiness, per-subsystem health and loaded-schedule count from the running service.
  • changed: Fire history is range-partitioned on PostgreSQL, so retention drops a partition instead of running a large delete. Python floor raised to 3.11.

v1.6.7 (2026-06-08)

  • changed: Python floor relaxed from 3.13 to 3.11 so the scheduler process runs on the same interpreter range as the brain.

z4j-django

v1.10.0 (2026-08-28)

  • changed: Carried with the coordinated 1.10.0 fleet release. No behaviour changed.

v1.9.1 (2026-08-27)

  • changed: Carried with the coordinated 1.9.1 fleet release. No behaviour changed.

v1.9.0 (2026-08-25)

  • changed: Aligned with the coordinated 1.9 runtime, security posture, and capability contracts.

v1.8.0 (2026-07-30)

  • changed: Aligned with the fleet release and its coordinated dependency floors, so a current adapter cannot be installed beside an incompatible dispatcher.

v1.7.0 (2026-07-14)

  • changed: Python floor raised to 3.11 and version unified with the rest of the fleet.

v1.6.9 (2026-06-23)

  • fixed: Clean shutdown on short-lived management commands: no more spurious error traceback at process exit.

v1.6.8 (2026-06-08)

  • security: Engine-extra floor lifted so `pip install z4j-django[rq]` resolves only the hardened RQ adapter line.

v1.6.7 (2026-06-08)

  • changed: Wider Django compatibility range: installs cleanly against Django 5.0 and up with no upper cap. Operator owns their own Django security posture; the adapter no longer gates on CVE versions.

z4j-fastapi

v1.10.0 (2026-08-28)

  • changed: Carried with the coordinated 1.10.0 fleet release. No behaviour changed.

v1.9.1 (2026-08-27)

  • changed: Carried with the coordinated 1.9.1 fleet release. No behaviour changed.

v1.9.0 (2026-08-25)

  • changed: The uncapped compatibility floor is FastAPI >=0.109.1, the first advisory-fixed release on the supported Pydantic 2 line.

v1.8.0 (2026-07-30)

  • changed: Version alignment with the fleet release. No functional change in this package.

v1.7.0 (2026-07-14)

  • changed: Python floor raised to 3.11 and version unified with the rest of the fleet.

v1.6.9 (2026-06-23)

  • fixed: Clean shutdown registration so the agent drains before the process worker pool is torn down.

v1.6.8 (2026-06-08)

  • security: Engine-extra floor lifted so `pip install z4j-fastapi[rq]` resolves only the hardened RQ adapter line.

v1.6.7 (2026-06-08)

  • changed: Compatibility floor corrected to FastAPI >=0.100, the first release compatible with z4j-core's Pydantic 2 floor, with no upper cap.

z4j-flask

v1.10.0 (2026-08-28)

  • changed: Carried with the coordinated 1.10.0 fleet release. No behaviour changed.

v1.9.1 (2026-08-27)

  • changed: Carried with the coordinated 1.9.1 fleet release. No behaviour changed.

v1.9.0 (2026-08-25)

  • changed: Aligned with the coordinated 1.9 runtime, security posture, and capability contracts.

v1.8.0 (2026-07-30)

  • changed: Aligned with the fleet release and its coordinated dependency floors, so a current adapter cannot be installed beside an incompatible dispatcher.

v1.7.0 (2026-07-14)

  • changed: Python floor raised to 3.11 and version unified with the rest of the fleet.

v1.6.9 (2026-06-23)

  • fixed: Clean shutdown registration so the agent drains before the process worker pool is torn down.

v1.6.8 (2026-06-08)

  • security: Engine-extra floor lifted so `pip install z4j-flask[rq]` resolves only the hardened RQ adapter line.

v1.6.7 (2026-06-08)

  • changed: Wider compatibility range: now installs against the lowest Flask version where every API z4j uses is present, with no upper cap. Operator-chosen primaries are no longer CVE-gated by the adapter; the operator owns their own framework security posture.

z4j-arq

v1.10.0 (2026-08-28)

  • changed: Carried with the coordinated 1.10.0 fleet release. No behaviour changed.

v1.9.1 (2026-08-27)

  • changed: Carried with the coordinated 1.9.1 fleet release. No behaviour changed.

v1.9.0 (2026-08-25)

  • changed: Aligned engine behavior and capability reporting with the coordinated 1.9 fleet.

v1.8.0 (2026-07-30)

  • changed: Version alignment with the fleet release. No functional change in this package.

v1.7.0 (2026-07-14)

  • fixed: Execution-path fixes surfaced by a fleet-wide readiness sweep, plus the Python floor raised to 3.11 and the whole fleet unified at a single version so an operator no longer has to reason about per-package version drift.

v1.6.7 (2026-06-08)

  • changed: Wider compatibility range: now installs against the lowest arq version where every API z4j uses is present, with no upper cap. Operator-chosen primaries are no longer CVE-gated by the adapter; the operator owns their own framework security posture.

z4j-celery

v1.10.0 (2026-08-28)

  • changed: Carried with the coordinated 1.10.0 fleet release. No behaviour changed.

v1.9.1 (2026-08-27)

  • changed: Carried with the coordinated 1.9.1 fleet release. No behaviour changed.

v1.9.0 (2026-08-25)

  • removed: Removed the unsafe dead-letter requeue capability. Direct calls now fail closed without publishing a duplicate task.
  • changed: The uncapped compatibility floor is Celery >=5.2.2, excluding the vulnerable 5.2.0/5.2.1 line.
  • fixed: Purge and engine behavior are aligned with the coordinated 1.9 capability contract.

v1.8.0 (2026-07-30)

  • changed: Retry authority is bound to the worker that executes it. The adapter advertises a versioned contract on its own live connection, so a retry cannot be handed to a colocated older worker that would run the task with empty arguments and report success. Package floors are coordinated across the fleet to match.

v1.7.0 (2026-07-14)

  • fixed: Execution-path fixes surfaced by a fleet-wide readiness sweep, plus the Python floor raised to 3.11 and the whole fleet unified at a single version so an operator no longer has to reason about per-package version drift.

v1.6.7 (2026-06-07)

  • fixed: Multi-tenant cache bleed fix. Worker-stats cache moved from class scope to instance scope so two adapters in the same process no longer share state.

z4j-dramatiq

v1.10.0 (2026-08-28)

  • changed: Carried with the coordinated 1.10.0 fleet release. No behaviour changed.

v1.9.1 (2026-08-27)

  • changed: Carried with the coordinated 1.9.1 fleet release. No behaviour changed.

v1.9.0 (2026-08-25)

  • changed: Removed advertised operations that stock Dramatiq cannot satisfy safely.

v1.8.0 (2026-07-30)

  • changed: Retry authority is bound to the worker that executes it. The adapter advertises a versioned contract on its own live connection, so a retry cannot be handed to a colocated older worker that would run the task with empty arguments and report success. Package floors are coordinated across the fleet to match.

v1.7.0 (2026-07-14)

  • fixed: Execution-path fixes surfaced by a fleet-wide readiness sweep, plus the Python floor raised to 3.11 and the whole fleet unified at a single version so an operator no longer has to reason about per-package version drift.

v1.6.7 (2026-06-08)

  • changed: Wider compatibility range: now installs against the lowest Dramatiq (>=1.14, <3) version where every API z4j uses is present, with no upper cap. Operator-chosen primaries are no longer CVE-gated by the adapter; the operator owns their own framework security posture.

z4j-huey

v1.10.0 (2026-08-28)

  • changed: Carried with the coordinated 1.10.0 fleet release. No behaviour changed.

v1.9.1 (2026-08-27)

  • changed: Carried with the coordinated 1.9.1 fleet release. No behaviour changed.

v1.9.0 (2026-08-25)

  • changed: Aligned engine behavior and capability reporting with the coordinated 1.9 fleet.

v1.8.0 (2026-07-30)

  • changed: Aligned with the fleet release and its coordinated dependency floors, so a current adapter cannot be installed beside an incompatible dispatcher.

v1.7.0 (2026-07-14)

  • fixed: Execution-path fixes surfaced by a fleet-wide readiness sweep, plus the Python floor raised to 3.11 and the whole fleet unified at a single version so an operator no longer has to reason about per-package version drift.

v1.6.7 (2026-06-08)

  • changed: Wider compatibility range: now installs against the lowest Huey (>=2.4, <3) version where every API z4j uses is present, with no upper cap. Operator-chosen primaries are no longer CVE-gated by the adapter; the operator owns their own framework security posture.

z4j-rq

v1.10.0 (2026-08-28)

  • changed: Carried with the coordinated 1.10.0 fleet release. No behaviour changed.

v1.9.1 (2026-08-27)

  • changed: Carried with the coordinated 1.9.1 fleet release. No behaviour changed.

v1.9.0 (2026-08-25)

  • changed: Engine actions now advertise and enforce only capabilities that the connected 1.9 worker can safely honor.

v1.8.0 (2026-07-30)

  • changed: Retry authority is bound to the worker that executes it. The adapter advertises a versioned contract on its own live connection, so a retry cannot be handed to a colocated older worker that would run the task with empty arguments and report success. Package floors are coordinated across the fleet to match.

v1.7.0 (2026-07-14)

  • fixed: Execution-path fixes surfaced by a fleet-wide readiness sweep, plus the Python floor raised to 3.11 and the whole fleet unified at a single version so an operator no longer has to reason about per-package version drift.

v1.6.7 (2026-06-08)

  • changed: Compatibility floor corrected to RQ >=1.10.1 with a <3 cap. RQ 1.10.0 cannot import on Python 3.12 and later.

z4j-taskiq

v1.10.0 (2026-08-28)

  • changed: Carried with the coordinated 1.10.0 fleet release. No behaviour changed.

v1.9.1 (2026-08-27)

  • changed: Carried with the coordinated 1.9.1 fleet release. No behaviour changed.

v1.9.0 (2026-08-25)

  • changed: Unsupported queue, ETA, and priority overrides now fail closed; broker operations require the correct owner event loop.

v1.8.0 (2026-07-30)

  • changed: Aligned with the fleet release and its coordinated dependency floors, so a current adapter cannot be installed beside an incompatible dispatcher.

v1.7.0 (2026-07-14)

  • fixed: Execution-path fixes surfaced by a fleet-wide readiness sweep, plus the Python floor raised to 3.11 and the whole fleet unified at a single version so an operator no longer has to reason about per-package version drift.

v1.6.7 (2026-06-08)

  • changed: Wider compatibility range: now installs against the lowest TaskIQ version where every API z4j uses is present, with no upper cap. Operator-chosen primaries are no longer CVE-gated by the adapter; the operator owns their own framework security posture.

z4j-apscheduler

v1.10.0 (2026-08-28)

  • changed: Carried with the coordinated 1.10.0 fleet release. No behaviour changed.

v1.9.1 (2026-08-27)

  • changed: Carried with the coordinated 1.9.1 fleet release. No behaviour changed.

v1.9.0 (2026-08-25)

  • changed: Aligned pause, resume, and capability behavior with the coordinated 1.9 scheduling contract.

v1.8.0 (2026-07-30)

  • changed: Aligned with the fleet release and its coordinated dependency floors, so a current adapter cannot be installed beside an incompatible dispatcher.

v1.7.0 (2026-07-14)

  • fixed: Scheduler execution-path fixes, the Python floor raised to 3.11, and version unified with the rest of the fleet.

v1.6.7 (2026-06-08)

  • changed: Compatibility floor corrected to APScheduler >=3.10.2 and <4. Earlier releases require the removed pkg_resources module at import time.

z4j-arqcron

v1.10.0 (2026-08-28)

  • changed: Carried with the coordinated 1.10.0 fleet release. No behaviour changed.

v1.9.1 (2026-08-27)

  • changed: Carried with the coordinated 1.9.1 fleet release. No behaviour changed.

v1.9.0 (2026-08-25)

  • changed: Aligned periodic scheduling behavior and dependency floors with the coordinated 1.9 fleet.

v1.8.0 (2026-07-30)

  • changed: Aligned with the fleet release and its coordinated dependency floors, so a current adapter cannot be installed beside an incompatible dispatcher.

v1.7.0 (2026-07-14)

  • fixed: Scheduler execution-path fixes, the Python floor raised to 3.11, and version unified with the rest of the fleet.

v1.6.7 (2026-06-08)

  • changed: Wider compatibility range: now installs against the lowest arq version where every API z4j uses is present, with no upper cap. Operator-chosen primaries are no longer CVE-gated by the adapter; the operator owns their own framework security posture.

z4j-celerybeat

v1.10.0 (2026-08-28)

  • changed: Carried with the coordinated 1.10.0 fleet release. No behaviour changed.

v1.9.1 (2026-08-27)

  • changed: Carried with the coordinated 1.9.1 fleet release. No behaviour changed.

v1.9.0 (2026-08-25)

  • changed: Aligned periodic scheduling behavior and dependency floors with the coordinated 1.9 fleet.

v1.8.0 (2026-07-30)

  • changed: Aligned with the fleet release and its coordinated dependency floors, so a current adapter cannot be installed beside an incompatible dispatcher.

v1.7.0 (2026-07-14)

  • fixed: Scheduler execution-path fixes, the Python floor raised to 3.11, and version unified with the rest of the fleet.

v1.6.7 (2026-06-08)

  • changed: Wider compatibility range: now installs against the lowest Celery (>=5.3) and django-celery-beat (>=2.5) version where every API z4j uses is present, with no upper cap. Operator-chosen primaries are no longer CVE-gated by the adapter; the operator owns their own framework security posture.

z4j-hueyperiodic

v1.10.0 (2026-08-28)

  • changed: Carried with the coordinated 1.10.0 fleet release. No behaviour changed.

v1.9.1 (2026-08-27)

  • changed: Carried with the coordinated 1.9.1 fleet release. No behaviour changed.

v1.9.0 (2026-08-25)

  • changed: Aligned periodic scheduling behavior and dependency floors with the coordinated 1.9 fleet.

v1.8.0 (2026-07-30)

  • changed: Aligned with the fleet release and its coordinated dependency floors, so a current adapter cannot be installed beside an incompatible dispatcher.

v1.7.0 (2026-07-14)

  • fixed: Scheduler execution-path fixes, the Python floor raised to 3.11, and version unified with the rest of the fleet.

v1.6.7 (2026-06-08)

  • changed: Wider compatibility range: now installs against the lowest Huey (>=2.4, <4) version where every API z4j uses is present, with no upper cap. Operator-chosen primaries are no longer CVE-gated by the adapter; the operator owns their own framework security posture.

z4j-rqscheduler

v1.10.0 (2026-08-28)

  • changed: Carried with the coordinated 1.10.0 fleet release. No behaviour changed.

v1.9.1 (2026-08-27)

  • changed: Carried with the coordinated 1.9.1 fleet release. No behaviour changed.

v1.9.0 (2026-08-25)

  • changed: No longer advertises an enable operation that cannot restore a removed schedule definition.

v1.8.0 (2026-07-30)

  • changed: Aligned with the fleet release and its coordinated dependency floors, so a current adapter cannot be installed beside an incompatible dispatcher.

v1.7.0 (2026-07-14)

  • fixed: Scheduler execution-path fixes, the Python floor raised to 3.11, and version unified with the rest of the fleet.

v1.6.7 (2026-06-08)

  • changed: Wider compatibility range: now installs against the lowest rq-scheduler (>=0.11) version where every API z4j uses is present, with no upper cap. Operator-chosen primaries are no longer CVE-gated by the adapter; the operator owns their own framework security posture.

z4j-taskiqscheduler

v1.10.0 (2026-08-28)

  • changed: Carried with the coordinated 1.10.0 fleet release. No behaviour changed.

v1.9.1 (2026-08-27)

  • changed: Carried with the coordinated 1.9.1 fleet release. No behaviour changed.

v1.9.0 (2026-08-25)

  • changed: Custom schedule-source operations now require the correct owner event loop and fail closed when it is unavailable.

v1.8.0 (2026-07-30)

  • changed: Aligned with the fleet release and its coordinated dependency floors, so a current adapter cannot be installed beside an incompatible dispatcher.

v1.7.0 (2026-07-14)

  • fixed: Scheduler execution-path fixes, the Python floor raised to 3.11, and version unified with the rest of the fleet.

v1.6.7 (2026-06-08)

  • changed: Wider compatibility range: now installs against the lowest TaskIQ version where every API z4j uses is present, with no upper cap. Operator-chosen primaries are no longer CVE-gated by the adapter; the operator owns their own framework security posture.