Skip to content

merge queue: checking #13 on main (a604a73) - #15

Closed
mergify[bot] wants to merge 2 commits into
mainfrom
mergify/merge-queue/1673bda600
Closed

mergify[bot] wants to merge 2 commits into
mainfrom
mergify/merge-queue/1673bda600

Conversation

@mergify

@mergify mergify Bot commented Oct 19, 2026 •

Copy link
Copy Markdown
Contributor

Note

This is a merge queue draft opened by Mergify. Nobody needs to act on it.
Mergify opened it for batch individual-nougat-d1wtw2 of the default queue, to test #13 before it merges into main. Pushing to this branch or closing this pull request removes #13 from the queue.

What this draft tests

Mergify checks that #13 still passes CI on top of main. CI runs on this draft's code, built in this order:

  1. main at a604a73
  2. #13, the pull request of this batch

🎉 Where it stands: checks passed

CI passed on this draft.

Follow the default queue in the dashboard

What happens next

  • Mergify merges #13 into main and closes this draft.
Metadata for CI tooling, read by mergify ci
---
all_scopes: false
checking_base_sha: a604a73b1f1856b386b87d8aacba6c49e30f3212
previous_check_retries: []
previous_failed_batches: []
pull_requests:
  - number: 13
    scopes: []
scopes: []
...
Required conditions of queue rule default for merge
Required conditions to stay in the queue

jd and others added 2 commits October 17, 2026 03:28
`uses: Mergifyio/setup-cli@v1` resolves the `v1` tag, and nothing has
moved that tag since v1.0.0: it still points at the first release, which
installs mergify-cli from PyPI through setup-python and uv. Every later
release (v1.1.0's prebuilt binary, v1.2.0, v1.3.0) is invisible to anyone
following the README's own advice to pin the major.

This adds a release workflow that, when a release is published, points
the major tag at the newest published release of that major. It picks
the newest one rather than the release that triggered it, so a patch on
an older minor cannot move `v1` backwards, and prereleases are skipped.
The tag is updated through the refs API, so a consumer never sees `v1`
missing mid-update. It can also be run by hand with a release tag, which
is how `v1` gets moved to v1.3.0 once this lands.

The README now says that `v1` follows the v1.x releases and how to stay
on one.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Change-Id: I879539b0c861a7d1d1a9f2f8cfd66b64419e4361
@mergify
mergify Bot deployed to Mergify Merge Protections October 19, 2026 08:30 Active
@mergify mergify Bot closed this Oct 19, 2026
@mergify
mergify Bot deleted the mergify/merge-queue/1673bda600 branch October 19, 2026 08:31

This branch was successfully deployed

1 active deployment
Mergify Merge Protections — 1e7bf931 Deployed Oct 19, 2026 by mergify[bot]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant