runner_q 0.6.4

Durable activity queue and worker system
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82

# Releasing runner_q and runner_q_redis

Both crates are published to [crates.io](https://crates.io) from this repo. **Versions can change independently.** The tag you push decides which crate(s) get published.

## Tag format → what gets published

| Tag | Publishes |
|-----|-----------|
| `v0.6.5` (plain) | **Both** — `runner_q` then `runner_q_redis` |
| `runner_q-v0.6.5` | **runner_q only** |
| `runner_q_redis-v0.1.2` | **runner_q_redis only** |

## Prerequisites

- Push access to the repo and permission to create tags.
- [crates.io](https://crates.io) auth configured for the repo (e.g. GitHub Actions with `crates-io-auth-action`).

## Draft release notes (Release Drafter)

On every push to `main`, [Release Drafter](https://github.com/release-drafter/release-drafter) updates **three** draft releases:

| Draft | Tag it will use when you publish |
|-------|-----------------------------------|
| **v0.6.6** (combined) | `v0.6.6` |
| **runner_q v0.6.6** | `runner_q-v0.6.6` |
| **runner_q_redis v0.1.1** | `runner_q_redis-v0.1.1` |

Each draft shows PRs merged since the last tag of that kind. When you’re ready to release, pick the draft that matches how you’re releasing (one crate or both), publish it so GitHub creates the tag, then the publish workflow will run and push to crates.io (or create the tag yourself and paste the draft notes into the release).

## Release flow

### Release one crate only

1. **Bump the version** in that crate’s `Cargo.toml`:
   - `runner_q` only → root `Cargo.toml` → `version`
   - `runner_q_redis` only → `runner_q_redis/Cargo.toml` → `version`

2. **Commit and push** the version bump.

3. **Create and push the tag** for that crate:
   ```bash
   # Release runner_q only (e.g. 0.6.5)
   git tag runner_q-v0.6.5
   git push origin runner_q-v0.6.5
   ```
   or
   ```bash
   # Release runner_q_redis only (e.g. 0.1.2)
   git tag runner_q_redis-v0.1.2
   git push origin runner_q_redis-v0.1.2
   ```

4. The workflow (`.github/workflows/release.yml`) publishes only the matching crate.

### Release both together

1. **Bump versions** in both `Cargo.toml` files.
   - To keep versions aligned, set both to the same value (e.g. `0.6.5`).
   - You can also bump each crate to its own next version if you version independently.

2. **Commit and push.**

3. **Tag with a plain `v` tag:**
   ```bash
   git tag v0.6.5
   git push origin v0.6.5
   ```

4. The workflow publishes `runner_q` first, then `runner_q_redis`.

## Version alignment (optional)

- You can keep **runner_q** and **runner_q_redis** on the same major/minor (e.g. both `0.6.x`) so `runner_q_redis = "0.6"` works with the published `runner_q`.
- Or version them independently (e.g. `runner_q` at `0.6.x`, `runner_q_redis` at `0.1.x`). When publishing `runner_q_redis`, the root `Cargo.toml` version of `runner_q` is what gets written as the dependency in the published crate — so that version of `runner_q` must already exist on crates.io.

## Troubleshooting

- **Publish fails for runner_q_redis**  
  The published dependency on `runner_q` is taken from the root `Cargo.toml`. Ensure that version of `runner_q` is already published to crates.io (e.g. release `runner_q` first with a `runner_q-v*` or `v*` tag).

- **Already published**  
  If the tag is re-used or the workflow re-runs, `cargo publish` will fail for a crate that’s already at that version. Bump the version, commit, and use a new tag.