Skip to content
cccskills
FreePublished on GitHub

fory-version-bump

Update Apache Fory version references across language packages, integration tests, examples, and source documentation. This skill distinguishes released versions from next development versions, applies the release helper, and checks for stale or misplaced version strings.

OriginalShow the original description

Bump Apache Fory release or post-release development versions across Java, Kotlin, Scala, Python, Rust, Go, C++, C#, Dart, JavaScript, Swift, integration tests, examples, and source docs. Use when preparing a release version, moving main to the next development version, switching install docs to a released version, or auditing Fory version consistency after release scripts run.

apache/fory4,576 stars(GitHub 4,576 + cccskills 0)

Run score Not tested

See how to install

Good for

  • Preparing versions for a Fory release
  • Moving package metadata to the next development version
  • Updating install docs to a released version
  • Auditing version consistency after release scripts

Files included (2)

  • SKILL.md4.2 KB
  • agents/openai.yaml1.1 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Fory Version Bump

Version Intent

Separate these two targets before editing:

  • Released version: use in install docs, examples, and package-manager snippets.
  • Next development version: use in active package and build metadata.

Do not edit fory-site unless the user explicitly includes that repository.

Ecosystem Version Forms

Let ci/release.py normalize the input instead of converting versions by hand.

For input 1.1.0-dev, expected forms are:

SurfaceExpected form
Java, Kotlin, Scala, Maven integration projects1.1.0-SNAPSHOT
Python and compiler packages1.1.0.dev0
Rust packages and path dependency versions1.1.0-alpha.0
Go module dependencies on Foryv1.1.0-alpha.0
JavaScript package versions1.1.0-alpha.0
Dart packages1.1.0-dev
C# package metadata1.1.0-dev
CMake project versions1.1.0
Bazel module version1.1.0
User install docs after a 1.0.0 release1.0.0

Workflow

  1. Read AGENTS.md, tasks/lessons.md, .agents/docs-and-formatting.md, and ./.local/AGENTS.md when present. Review git status --short --branch.
  2. Record the released and next-development versions in the task file.
  3. For a post-release bump, run:
python ci/release.py bump_version -l all -version <next-dev-version> \
  -release-version <released-version>
  1. Inspect the complete diff. The helper should update package/build metadata, source docs, examples, and these historically missed surfaces:
  • MODULE.bazel
  • javascript/package-lock.json
  • integration_tests/idl_tests/kotlin/pom.xml
  • integration_tests/idl_tests/dart/pubspec.yaml
  • integration_tests/idl_tests/rust/Cargo.lock
  • dart/CHANGELOG.md and dart/packages/fory/CHANGELOG.md
  • scala/fory-scala/README.md and scala/fory-json-scala/README.md
  1. Search for stale previous development forms and accidental next-development versions in user-facing docs:
rg -n '<previous-development-version-regex>' \
  --glob '!tasks/**' --glob '!**/target/**' --glob '!**/build/**' \
  --glob '!**/bin/**' --glob '!**/obj/**' --glob '!**/node_modules/**'
rg -n '<next-development-version-regex>' \
  README.md docs csharp/README.md swift/README.md scala/README.md \
  java/README.md rust/README.md dart/packages/fory/README.md examples \
  --glob '!**/target/**' --glob '!**/build/**' --glob '!**/node_modules/**'

Inspect every hit. Keep unrelated third-party versions, benchmark numbers, historical changelog entries, test fixtures, and ignored build outputs unchanged.

  1. Format changed Markdown and check the patch:
prettier --write <changed-markdown-files>
git diff --check

Verification Boundary

Treat a version-only bump as a textual metadata and documentation update. Do not run unit tests, builds, Maven, CMake, Cargo metadata, package-manager validation, or language test suites locally, including through subagents, unless the user explicitly asks. CI owns those checks.

Verify only that:

  • each ecosystem uses the expected version form;
  • install docs use the released version and development metadata uses the next version;
  • changelogs contain the released version before the next development section;
  • no unexplained stale development version remains;
  • formatting and git diff --check pass; and
  • task files are not staged.

Finish

  • Summarize exact version forms used by ecosystem.
  • Note any intentionally retained old version hits.
  • Commit tracked code and documentation changes, excluding task scratch files.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Improve Apache Fory serialization and deserialization performance across its language implementations. The skill profiles bottlenecks, compares paired benchmarks against a baseline, and guides focused changes while checking correctness and cross-language compatibility.

  • Finding serialization or deserialization bottlenecks
  • Investigating a performance regression against a reference commit
  • Diagnosing flamegraphs or performance CI failures
apache/fory4.6KUpdated Oct 27, 2026

fory-release

FreeSummary

Prepare an Apache Fory release candidate by coordinating the version bump, immutable RC tag, JVM artifact staging, signed source archive, and ASF Subversion upload. It also drafts a verifiable vote email using the release outputs and required checks.

  • Preparing a new Apache Fory release candidate
  • Resuming an interrupted Fory release workflow
  • Drafting a vote email after artifact checks
apache/fory4.6KUpdated Oct 27, 2026

See all skills by apache

Report a problem with this skill