Skip to content

chore(main): release labops 0.10.0 - #70

Merged
FreezeManny merged 1 commit into
mainfrom
release-please--branches--main--components--labops
Aug 19, 2026
Merged

chore(main): release labops 0.10.0#70
FreezeManny merged 1 commit into
mainfrom
release-please--branches--main--components--labops

Conversation

@FreezeManny

@FreezeManny FreezeManny commented Aug 19, 2026

Copy link
Copy Markdown
Owner

🤖 I have created a release beep boop

0.10.0 (2026-08-19)

Features

Bug Fixes


This PR was generated with Release Please. See documentation.

@FreezeManny
FreezeManny force-pushed the release-please--branches--main--components--labops branch from ecb3968 to ef7204c Compare August 19, 2026 10:40
FreezeManny added a commit that referenced this pull request Aug 19, 2026
Closes #73.

## Problem

`uv sync --locked` fails on every release PR (e.g. #70):

```
error: The lockfile at `uv.lock` needs to be updated, but `--locked` was provided.
```

uv records a `version` for the root package in `uv.lock` only when
`pyproject.toml` states one statically. release-please bumps
`pyproject.toml` and leaves the lock behind, so the two disagree.

The blast radius is wider than the release PR: `Test` runs on
`pull_request`, so once a release PR merges, the stale lock lands on
main and **every subsequent PR** fails the same way. `Docs` (`uv sync
--locked --group docs`, on `release: published`) would fail on the
release itself. `Publish` is unaffected — it only runs `uv build`.

## Fix

Make the version dynamic. With `dynamic = ["version"]`, uv omits the
field from the lock entirely, so a release bump cannot desynchronise it
and `--locked` stays strict for the dependabot PRs it was added for.

| root version | after a 0.9.1 → 0.10.0 bump | `uv lock --check` |
|---|---|---|
| static (before) | lock now stale | fails |
| dynamic (after) | lock unchanged — no version recorded | passes |

release-please now updates `src/__about__.py` through its **generic**
(comment-annotation) updater instead.

## Also dropped

The `uv.lock` entry added to `release-please-config.json` in #72 was a
silent no-op. Its jsonpath is evaluated by `jsonpath-plus`, which does
not apply the `[?(@.name=='labops')]` filter, so it matched nothing and
only logged a warning — visible in the Release Please run for #70:

```
⚠ No entries modified in $.package[?(@.name=='labops')].version
```

Non-matching paths only warn, never fail, which is why #72 looked like
it worked.

## Verification

- `uv lock` → `Updated labops v0.9.1 -> (dynamic)`; the `version` field
is gone from the lock
- `uv sync --locked` passes from a clean environment and installs
`labops==0.9.1`
- bumping `__about__.py` to `0.10.0` leaves `uv lock --check` passing,
and `uv build` produces `labops-0.10.0` artifacts
- 550 tests pass; `ruff check` clean

Not verifiable locally: that release-please actually rewrites the
annotated line — that only proves out on the next Release Please run. It
uses the annotation-based generic updater rather than the jsonpath path
that failed before.

## After merge

release-please regenerates #70 against the new config, bumping
`src/__about__.py` instead of `pyproject.toml`, and its stale-lock diff
disappears.
@FreezeManny
FreezeManny force-pushed the release-please--branches--main--components--labops branch from ef7204c to d634225 Compare August 19, 2026 11:45
@FreezeManny
FreezeManny merged commit 03eb841 into main Aug 19, 2026
2 checks passed
@FreezeManny

Copy link
Copy Markdown
Owner Author

🤖 Created releases:

🌻

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant