免费在 GitHub 公开

prerelease

Tag and push a prerelease from the current Cargo.toml version. Use when the user wants to cut an alpha/beta/rc prerelease. Aborts on stable versions (no `-` in version string) and if the tag already exists.

中文简介正在准备中。当前显示原文说明。

iopsystems/rezolus

查看安装方法

包含的文件（1）

SKILL.md2.0 KB

SKILL.md（原文）

安装前可以查看交给 AI 代理的指令内容。

Tag and push a prerelease to upstream (iopsystems/rezolus).

The release.yml CI workflow triggers on any v* tag push and automatically marks the GitHub release as a pre-release when the tag contains - (e.g. -alpha.8). Package registries and Homebrew are only updated for stable releases.

Steps

Verify prerequisites:

Must be on main branch
Working directory must be clean

if [ "$(git branch --show-current)" != "main" ]; then
  echo "Error: Must be on main branch"
  exit 1
fi
if [ -n "$(git status --porcelain)" ]; then
  echo "Error: Working directory not clean"
  exit 1
fi

Read version and validate it is a prerelease:

VERSION=$(grep '^version = ' Cargo.toml | head -1 | sed 's/version = "\(.*\)"/\1/')
echo "Current version: $VERSION"

if [[ "$VERSION" != *"-"* ]]; then
  echo "Error: $VERSION looks like a stable release (no prerelease suffix)."
  echo "Stable releases are handled by the tag-release CI workflow."
  echo "Commit with message 'release: prepare v$VERSION' on main instead."
  exit 1
fi

Check the tag does not already exist on upstream:

TAG="v$VERSION"
if git ls-remote --tags upstream "$TAG" | grep -q "$TAG"; then
  echo "Error: Tag $TAG already exists on upstream. Nothing to do."
  exit 1
fi

Create annotated tag and push to upstream:

echo "Creating prerelease tag $TAG and pushing to upstream."
echo "CI will build packages and create a GitHub pre-release."
git tag -a "$TAG" -m "Prerelease $TAG"
git push upstream "$TAG"

Report the GitHub release URL:

https://github.com/iopsystems/rezolus/releases/tag/$TAG

评价

还没有评价。欢迎分享你的使用感受。

无需登录即可发表。欢迎分享使用感受、提问，或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

同一仓库的技能

document-feature

免费

Write or update the CLI `--help` text and README section for a new or changed rezolus feature (a subcommand, flag, mode, or behavior change), then prove the help is usable by dispatching a fresh subagent that has never seen the code. Use this whenever you add or change how rezolus is invoked — new `rezolus <subcommand>`, new flags/args on an existing mode, renamed options, or changed defaults — and any time the user says the help/README is thin, stale, confusing, or "an agent couldn't figure this out." Treats help text as an interface under test, not prose.

中文简介正在准备中。当前显示原文说明。