Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,6 +8,8 @@ changelog does not include internal changes that do not affect the user.

## [Unreleased]

## [0.16.0] - 2026-06-21

### Added

- Added `COSMOS` from [Scalable Pareto Front Approximation for Deep Multi-Objective
Expand Down
2 changes: 1 addition & 1 deletion pyproject.toml
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"

[project]
name = "torchjd"
version = "0.15.0"
version = "0.16.0"
description = "Library for Jacobian Descent with PyTorch."
readme = "README.md"
authors = [
Expand Down
98 changes: 98 additions & 0 deletions skills/prepare-release/SKILL.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,98 @@
---
name: prepare-release
description: Prepares a torchjd package release by verifying the changelog, README, bumping the version in pyproject.toml, and opening a release PR. Use when a maintainer asks to prepare a release or to release.
---

# Prepare TorchJD Release

This skill covers the pre-merge steps of the release process.

**For agents:** invoke as `/prepare-release X.Y.Z` (e.g. `/prepare-release 0.16.0`).
If no version is provided, read the current version from `pyproject.toml` and ask the user
what the new version should be before proceeding.

**For humans:** follow the numbered steps below in your terminal.
Replace `X.Y.Z` with the version you are releasing and `yyyy-mm-dd` with today's date.

---

## Instructions

### Step 1: Determine the version

Read `pyproject.toml` to find the current `version` field under `[project]`. The new release
version is either provided as an argument or must be confirmed with the user before continuing.

Verify it follows [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

### Step 2: Verify CHANGELOG

Read `CHANGELOG.md` and compare it against the commits done since the last version release. Verify that no user-facing change was forgotten, and that all were correctly added under the [Unreleased] section.

### Step 3: Check README for interface changes

Read `CHANGELOG.md` and identify any entries in the `[Unreleased]` section that affect the public
interface (new or removed classes, functions, or arguments; changed signatures or behavior).

If such entries exist, read `README.md` and verify it accurately describes the current interface.

If a table listing methods exists in `README.md`, add to it any newly added method of the corresponding type.

If anything else seems missing, report that to the user.

### Step 4: Run the unit tests

CRITICAL: Do not skip this step, even partially.

Run the unit tests and confirm they all pass both on CPU and GPU (you need a CUDA-enabled GPU for this):

```bash
uv run pytest tests/unit
PYTEST_TORCH_DEVICE=cuda:0 uv run pytest tests/unit
```

If any tests fail, stop and report the failures. Do not proceed to the next steps.

### Step 5: Add the version header to the changelog

In `CHANGELOG.md`, insert a new `## [X.Y.Z] - yyyy-mm-dd` heading immediately after the blank
line that follows `## [Unreleased]`, before the existing subsections:

```diff
## [Unreleased]

+## [X.Y.Z] - yyyy-mm-dd
+
### Added
```

The `[Unreleased]` section stays in place and will accumulate entries for the next release.
The newly-inserted heading claims the existing content as its own.

### Step 6: Bump the version in `pyproject.toml`

In `pyproject.toml`, update the `version` field under `[project]`:

```diff
-version = "A.B.C"
+version = "X.Y.Z"
```

### Step 7: Open the release PR

Stage changes, then open a pull request targeting `main`.
Return the PR URL when done.

### Step 8: Create a draft release on GitHub

CRITICAL: The release you'll create should ALWAYS be a draft. Never even suggest to make the real release. A maintainer will manually release the draft if it seems ready.

The command should be:
```
gh release create vX.Y.Z --draft --title vX.Y.Z --notes "<insert notes here>"
```

To write the actual release notes, look at what is done in recent releases and suggest the new notes. Make it short. Also, prompt the user for an good-looking emoji (propose a list of 10) to use in the main section of the release notes.

---

Loading