Publishing & versioning

Publishing turns a dotjob.yaml into a listing anyone can install. Every version is reviewed, and semantic versioning decides how updates reach existing installs.

Publishing flow

1. 1

   Write the package

   Author dotjob.yaml following the package format. Validate locally with the CLI once released.
2. 2

   Test runs

   Run against your own Dot with your own connections. Fix guarantee violations until runs are clean.
3. 3

   Submit for review

   Review checks declared connections against actual capability calls, reads the steps for data handling, and verifies guarantees.
4. 4

   Listed

   Your job appears in its category with your publisher name. You can edit listing copy without a new version.
5. 5

   Iterate

   Publish new versions. Patch and minor versions roll out automatically; majors are offered as upgrades.

Semantic versioning

version: 1.4.0   # major.minor.patch
# 1.4.1  fixed a parsing bug                      → auto
# 1.5.0  added optional "regions" input           → auto, default applies
# 2.0.0  now requires a Notion connection         → upgrade offer

What review looks for

• Least privilege. Every app in connects is actually used; every connection input has the narrowest scope that works.
• Honest listing. Title, tagline and outputs match what the steps produce.
• Guarantees. Read-only jobs declare read_only; writing jobs declare no_writes_outside_destination.
• Safety flags. safe: true is only on steps that are trivial to undo.
• No data exfiltration. Nothing leaves the user's Dot except to declared destinations.

Earning

Builders keep 80% of net revenue on every run and renewal, paid monthly. The full terms are on the builder payouts page.

Tooling