v0.2.1

A documentation and release-tooling release. The code that runs is the same as in 0.2.0.

Fixed

• The README, the Python package's README (its PyPI page) and the book now say exactly what the
  code does:
  • aging lets long-waiting background work overtake ordinary work, but never High or
    Critical work;
  • fixed starts and cron runs reserve capacity ahead of their start, and a run that cannot
    get it is reported as a conflict;
  • a token's tenant applies to what it submits, and does not hide other tenants' tasks;
  • workers use attempt numbers as fencing tokens, and the server fences reports by lease;
  • client calls reach the right shard through any server, and workers are redirected to it;
  • KEDA reads the desired-capacity metric; there is no KEDA scaler;
  • OpenTelemetry metrics and trace propagation are in the Rust library only;
  • resources are shared within a shard, and SQLite standbys run on the same host;
  • choosing the next task looks only at queue heads, and re-queuing a retried task into a
    very long queue moves the entries behind it.
• The Rust crate's documentation no longer calls aging starvation-free.
• Every quickstart in the README and the book runs as written: the Python client and worker
  snippets use asyncio.run, and the server quickstarts use the published container image.
• The README has an install section for every package.
• The release workflow publishes the TypeScript package by file path. In 0.2.0, npm read the
  path as a GitHub repository, and the package was published afterwards with the new manual
  Finish release workflow.

Project

• The Go SDK's sdks/go/v0.2.0 tag points at the commit before the 0.2.0 release tag; its
  code is the same. From 0.2.1, the Go SDK tag and the release tag point at the same commit.
• The TypeScript tests no longer race for ports or leave a log file open per server start.

cronoq 0.2.0

This is cronoq's first public release. No 0.1.0 was published.

cronoq is a task scheduler that decides when work runs, in what order and how much capacity it
needs. Your code decides where the work runs: async functions in your process, Python
coroutines, or remote workers connected over gRPC. The same engine, with the same rules and
metrics, sits behind the Rust library, the Python package and the server.

What's in it

• Priorities that don't starve. Four priority classes, with aging so background work still
  finishes, and earliest-deadline-first ordering for tasks with deadlines.
• Cron with reserved capacity. A fixed-start task reserves capacity when it is submitted,
  and a worker is held free just before its start. A cron schedule can set a time zone, an
  overlap policy and a deadline relative to each occurrence.
• Dependencies and batches. Edges on success, failure or completion, atomic batches and
  idempotent keys.
• Rate limits before dispatch. Shared token buckets and semaphores. A task that waits for a
  limit does not hold a worker, and a worker can return retry_after.
• Fair sharing and worker labels. A pool can split capacity between tenants by weight
  within each priority class. Tasks can require worker labels, such as gpu=a100.
• Autoscaling from queue pressure. Each pool gets a desired capacity from its arrival rate,
  backlog, wait-time objectives and upcoming reservations. A webhook, KEDA or the included
  Kubernetes operator can act on it.
• Durability and failover. Leases, heartbeats, retries with backoff and dead letters. With a
  Postgres or SQLite store, a standby takes over when the leader stops. Attempt numbers serve as
  fencing tokens for effectively-once side effects.
• Sharding. Pools can be split between shards, each with its own leader and store. Any
  server forwards calls to the shard that owns the pool, and workers follow their pool to the
  right shard.
• Clients for other languages. A Go SDK and a TypeScript SDK (Node, and browsers over
  gRPC-Web) sit next to the Rust and Python clients. The cronoq command-line tool includes a
  live top view.
• Safe defaults. The server listens only on loopback until credentials are configured.
  Tokens have roles and can be limited to pools and tenants. TLS and mTLS are supported on both
  listeners, and every request is bounded by [limits].

The engine makes about a million scheduling decisions per second per core. Dispatch cost grows
only with the logarithm of the backlog.

Install

What	How
Rust library	cargo add cronoq@0.2
Python (3.14+)	pip install cronoq, or pip install "cronoq[client]" for the gRPC client and worker
Server binaries	Download cronoq-server-v0.2.0-<target> below (Linux, macOS, Windows; each includes the cronoq CLI)
Container image	ghcr.io/synaptiai/cronoq:0.2.0 (server and CLI); ghcr.io/synaptiai/cronoq-operator:0.2.0
Helm charts	helm install cronoq oci://ghcr.io/synaptiai/charts/cronoq --version 0.2.0, and .../charts/cronoq-operator
Command-line tool	cargo install cronoq-cli
Go SDK	go get github.com/synaptiai/cronoq/sdks/go@v0.2.0
TypeScript SDK	@synaptiai/cronoq on GitHub Packages, or npm install the synaptiai-cronoq-0.2.0.tgz attached below

On Windows on arm64, cronoq[client] needs grpcio, which has no prebuilt wheel there; the
engine bindings (pip install cronoq) install on every platform.

GitHub Packages needs a GitHub token with read:packages to install npm packages, public ones
included. The tarball attached to this release installs without one. The
TypeScript reference shows both
ways.

Wheels, server binaries, container images and the TypeScript package carry build provenance
attestations. Check one with gh attestation verify <file> --repo synaptiai/cronoq.

Getting started

• Documentation: concepts, use cases, guides and
  references.
• Benefits at a glance: which symptoms
  cronoq addresses, where to start, and the trade-offs.
• Quickstarts for Rust,
  Python and
  the server.

Compatibility

Before 1.0, a minor version may contain breaking changes; the changelog lists them under
Changed. The Rust crates need Rust 1.94 or newer, the Python package CPython 3.14 or newer,
the Go SDK Go 1.26 or newer, and the TypeScript SDK Node 22 or newer. Workers speak worker
protocol version 3.

Report security issues privately as SECURITY.md
describes. Questions and ideas are welcome in
Discussions.

The changelog
lists everything in this release.